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SECTION 1 


INTRODUCTION AND OVERVIEW 


1.1 Introduction 


This report contains a description of the functional design of I/O Ser- 
vices for the AIPS Proof of Concept System. 

The design methodology employed is based on the use of data flow analy- 
sis techniques. The methodology is more fully described in references 
[6], [7], and [9] . 

Section " 2. Data Flow Diagrams" contains the data flow diagrams, which 
show the functional processes in I/O Services and the data that flows 
among them. The data flow diagrams are organized in a hierarchical man- 
ner. I/O Services is divided into two primary categories: providing 
services to acquire or deliver data to and from devices such as sensors 
and effectors, and maintaining the I/O System in functioning order. The 
former category is referred to as I/O User Communication Services and 
the latter as I/O Network Management. 

Section " 3. Process Descriptions" contains a description of every pro- 
cess. The data flow diagrams, process reference numbers, and identifi- 
ers illustrate the hierarchical relationship of the processes. 

Section " 4. Data Dictionary" contains a complete list of the data 
identified on the data flow diagrams and in the process descriptions. A 
brief description is included with each entry. 

Section " 5. Process and Data Location" specifies the physical location 
of the processes and data. It also identifies whether the process is 
performed by hardware or by software. 

Appendix " A. Data Flow Diagram Symbol Definitions" contains defi- 
nitions of the symbols used on the data flow diagrams. 

Appendix " B. Process Description Format Explanation" contains an 
explanation of the format of the Process Descriptions. 

Appendix " C. Glossary of I/O Terms" contains a glossary of I/O terms 
used in the AIPS Proof of Concept System. 


1.2 Design Overview 


The overall design of I/O Network Services separates the I/O Network 
Manager from I/O User Communication Services so as to support the system 
level requirements regarding growth, change, and modularity. Specif- 
ically, the Network Manager manages the I/O network itself (but not the 
nonmanagers subscribers and their root interfaces). Each subscriber 
GPC's I/O User Communication Service manages its own root interfaces to 
the network. And each User (Application) Function, in conjunction with 
the I/O User Communication Services, manages its use of the DIUs. This 
functional separation allows the Network Manager to perform its func- 
tions largely independently of the subscribers and without the need to 
track the hardware or software configurations of the GPC subscribers and 
the application functions. 

The next two sections give a brief overview of the major design charac- 
teristics of I/O User Communication Services and I/O Network Management. 


1.2*1 I/P User Communication Services 

I/O User Communication Services provides two general categories of ser- 
vice. The first covers requests for the transmission and reception of 
data between a GPC and an I/O device external to the GPC. The second 
category covers requests for utility services to modify certain charac- 
teristics of the first category of service. Transaction selection, 
bypass clear, and initialization are examples of this second category of 
service. 

The system level performance requirements regarding I/O response time 
and transport lag significantly influenced the design of I/O User Commu- 
nication Services. 

Since it was desired to provide a user interface that is largely trans- 
parent to the actual construction and current connectivity state of the 
I/O networks, it was necessary to provide a method of mapping a user 
request for data service into the particulars of networks and DIUs. The 
design approach was influenced by two significant factors: 

• The I/O networks are contention networks, i.e., each GPC sub- 
scriber must win a contention before utilizing the network, and 
the cost of the contention (in time) is not insignificant. 

• Many applications require that the time relationship among the 
reading and writing of data to various sensors and effectors 
within the same user request be controlled. 

These factors led to the design that permits reading and writing to mul- 
tiple devices on the same network under the umbrella of a single con- 
tention sequence: a chain. 

It is possible that a user request will involve devices that are con- 
nected to different I/O networks. In this case, it is not practical to 
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provide controlled time relationship across the networks because of the 
difficulty of acquiring contention control of multiple networks; indeed, 
any scheme to accomplish this would have to avoid a possible deadlock 
situation. However, an application system designer can achieve the 
effects of simultaneous access control over multiple networks by parti- 
tioning a single network. This allows a user, for example, to simul- 
taneously read redundant versions of a sensor by placing the redundant 
versions in different partitions of the network. 

Since most application functions execute the same I/O transactions 
repeatedly, the design utilizes the concept of predefined chains that 
are for the most part fixed in nature. A design that permitted only 
totally rigid chains would, however, lead in some instances to the need 
for a large number of chains, some being slight variations of each 
other. To avoid this, the Transaction Selection feature is provided. 
This service permits the user to specify which of the transactions with- 
in a chain will be performed and which will not be performed. A 
selection, once made, is effective for all occurrences of the chain 
until a new selection is made. 

To support the need for a general initialization feature at the initi- 
ation of an application function, the Function Initialization feature is 
provided. Its invocation restores all of an application function's data 
transmission and reception requests to their initial state. 

The consideration of I/O communication errors and their causes influ- 
enced- the des i gn in a number of ways . 

A GPC, a Dili, or the network itself can be the source of an I/O error. 
The decision to functionally separate the I/O Network Manager from I/O 
User Communication Services places the responsibility for the isolation 
of network and babbling subscriber faults with the Network Manager and 
the responsibility for isolating GPC interface and DIU faults with the 
I/O User Communication Services. 

The approach used to isolate DIU faults is to successively omit errored 
transactions from the chain until it no longer accesses the suspect DIU: 
this action is referred to as transaction bypass. However, since net- 
work errors can result in the same effects, it is necessary for the net- 
work manager to inform each of the GPC subscribers on the network 
following a repair operation so that any bypassed transactions can be 
reinstated; this operation is called Bypass Clear . In general, when a 
transaction within a chain is bypassed, the chain as a whole is short- 
ened by the duration of that transaction. However, in the case of a par- 
titioned network, an equivalent time pad is substituted for the bypassed 
transaction so as to maintain the simultaneity of operations on the var- 
ious parallel partitions. 

To insure nonconflicting usage of a particular I/O network by the same 
or multiple users within the same GPC, the design approach is to perform 
all requests of either the data or utility type serially and without 
overlap. Thus, for example, a Transaction Selection request that is 
entered for a particular chain while that chain is being performed for 
some other request will not be executed until processing for the current 
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chain is completed. However, the design places no restriction on the 
simultaneous performance of operations on separate I/O networks. 


1.2.2 I/O Network Management 

An I/O network is a reconf igurable, virtual bus which allows GPC sub- 
scribers to access input/output devices or DIUs connected to the bus. 
The reconfigurability feature is allowed by the 5-ported nodes which 
join the various communications elements into a network [5]. These 
nodes provide more than the minimum number of links required to form the 
bus. Under control of the I/O Network Manager, the spare links can be 
brought into service in response to a network failure, thus restoring 
I/O service and increasing the reliability of the network. Furthermore, 
on-line modifications of the network are permitted. These modifications 
can range from the reinstallation of a repaired node to the addition of 
new nodes and links. 

A GPC subscriber to the network may be a Fault Tolerant Processor (FTP) 
consisting of two or three synchronously operating, simplex channels. 
Each channel can have a connection to one and only one node of a partic- 
ular network. This root node is connected to its channel by a root 
link. Thus a triplex GPC may have up to three root links to a partic- 
ular I/O network. However, it may have two or only one root link. A 
simplex GPC can have only one root link to a network. Regardless of 
the level of redundancy, of each GPC, the data on the network is simplex 
data from a single source. The replication of congruent data for each 
channel is handled by the FTP interchannel data exchange mechanism [4]. 

A Network Manager is a process operating within one of the GPC subscrib- 
ers. The primary function of this process is to maintain the health of 
the network by finding faulty components and reconfiguring the active 
network to exclude them. To do this it uses a data base which reflects 
the actual physical connections in the network and real time data which 
it periodically collects from the network nodes themselves. 

Networks may serve the I/O needs of several GPCs (a regional network) or 
only one (a local network). In the case where several GPC utilize a 
network, only one of them (at any one time) will host the Network Manag- 
er of that network. The choice of this host processor should reflect the 
consideration that the greater the number of root links a GPC has to a 
network, the greater its ability to maintain a connection to the net- 
work. 

If a network is dedicated to only one GPC, a unique network configura- 
tion is possible, namely a partitioned network. Such a network may be 
partitioned into as many subnetworks as the GPC owner of the network has 
root links. These subnetworks are a set of redundant parallel virtual 
buses, each conducting I/O operations with redundant, parallel QIUs. 
Within each subnetwork are a certain number of spare links which allow 
failures to be repaired intrapartition. An advantageous feature of this 
configuration is that while such a repair is taking place, other parti- 
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tions can operate normally allowing I/O functions to continue uninter- 
rupted. Nevertheless, the potential to merge two or more partitions is 
available in the event that intrapartition repair becomes impossible. 
For example, in the event of a root link failure, I/O devices in the 
temporarily isolated partition can be brought back on the bus by utiliz- 
ing one of the spare links that connect two partitions of the network. 
If critical information is at stake, such a* departi tioning could be used 
to attempt recovery of even one isolated node. 

While a GPC may have several root links to an unpartitioned network, 
only one of these may be active at any one time. Similarly, in a parti- 
tioned network, each partition may have only one active root link to its 
GPC. This is to prevent two channels from simultaneously utilizing the 
bus and corrupting each other's signals. The manager of a network does 
not in general control the root link connection of a GPC to a network. 
This must clearly be the case when a GPC accesses a network but does not 
manage it. In such a distributed system, the manager may not have suf- 
ficient data to control the network interface to its nonhost GPCs. 
Thus, the manager will configure each root node so that the port 
attached to a root link is always active, i.e. capable of transmitting 
and receiving data. The GPC root link selection process will then 
choose which root node it will actively communicate through. The manag- 
er process will control the configuration of its host GPC's interface 
only when it is growing the network and when it is reconfiguring the 
network in response to a network failure. 

The manager of the network can isolate network faults and restore I/O 
service in the face of several types of network faults. These include a 
passively failed node or node port, a babbling node or subscriber, and a 
node which responds out of turn when other nodes are addressed. The 
manager determines the identity of the faulty element and reconfigures 
the network so as to isolate that element. The manager periodically 
tests failed nodes and node ports to determine if the failure was tran- 
sient in nature. 

Finally, the manager of an I/O network performs its functions such that 
they are largely transparent to all applications using the network for 
I/O service. 
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SECTION 2 

DATA FLOW DIAGRAMS 


The top level organization of I/O Services functions is depicted in Fig- 
ure 2-1. As illustrated, the functions are divided into two categories: 
I/O User Communication Services processing and I/O Network Manager proc- 
essing. I/O User Communication Services data flow diagrams are con- 
tained In section "2.1 I/O User Communication Services" on page 2-7. 
I/O Network Manager data flow diagrams are in section "2.2 I/O Network 
Manager" on page 2-31 . 



Figure 2-1. AIPS Proof of Concept I/O System Servi'ces - Top Level 


The context of the I/O System Services data flow within the AIPS Proof 
of Concept System is shown in Figure 2-2. The data flow between the 
major categories of I/O System Services is shown in Figure 2-3. 
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2.1 I/O User Communication Services 


I/O User Communication Services provides two general categories of ser- 
vice. The first covers requests for the transmittal and retrieval of 
data between a GPC and some I/O device external to the GPC. The second 
category covers requests for utility services to modify certain charac- 
teristics of the first category of service. Transaction selection, 
bypass clear, and initialization are examples of this second category of 
service. All of these services are processed by I/O Request Processing. 
I/O User Communication Services data flow diagrams are in Figure 2-5 on 
page 2-11 through Figure 2-14 on page 2-29 . The hierarchical relation- 
ship of these flow diagrams and processes is shown in Figure 2-4. 
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Figure 2-5. I/O User Communication Services - 4.1 
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Figure 2-8. Queue Processing - 4.1 .2.1 
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Figure 2-14. GPC I/O Network Manager Support - 4.1.4 
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2.2 I/O Network Manager 


I/O Network Manager processing is divided into three groups: Network 
Control, Network Monitoring, and Network Status Reporting. The data 
flow diagrams are in Figure 2-16 on page 2-35 through Figure 2-22 on 
page 2-47 . The hierarchical relationship of these flow diagrams and 
processes is illustrated in Figure 2-15 on page 2-32. 
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Figure 2-16. I/O Network Manager - 4.2. 
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Figure 2-19. Initialize I/O Network - 4.2.1 .2 
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Figure 2-20. Maintain I/O Network - 4. 2. 1.3 
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SECTION— 3 


PROCESS DESCRIPTIONS 


This section contains a description of each process identified in the 
data flow diagrams. The descriptions are in a standard format which is 
described in appendix " B. Process Description Format Explanation." 


3.1 I/O User Commun i cat i on Services Processes 


Process Name: 
Reference Number: 
Identifier: 

Bui Id: 


I/O User Communication Services 
4.1 

ICLSy s tem_Serv i ces . - 

10 User Commun i cat ion^Servi ces 

3 — 


Requ-i remen ts Reference: POC System I/O Services Fu nctional Require- 

ments . Chapter 3 


Inputs: 

• GPC_Subscr i ber_Command .from System Manager (1.) 

• I0_Reques ^Parameter from Application Functions 

• Response_Frame from DIUs 

• I0_Data_Base 

• Reconf iguration_Report from I/O Network Manager (4.2) 

• Manager IO_Request_Parameter from I/O Network Manager 

(4.2) 

Outputs: 

• Local_I0_ Status to Local System Services (3.) 

• IO_Request_Data_And_Status to Application Functions 

• Wait_Request to Local Operating System 

• Command_Frame to DIUs 

• GPC_Subscr iber_IO_Error_Report to I/O Network Manager 

(4.2) 

• Manager_IO_Request_Data_And_Status to I/O Network Man- 
ager (4.2) 

• GPC_Subscr iber_I0_Error_Log to System Manager (1.) 


Notes: 


This process must exist at each processing site which 
provides I/O services to resident functions. 


Description: 
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This process provides communication to OIUs and Nodes throughout the 
system. It handles all requests for the following communication ser- 
vices: 

• Communication with nodes and DIUs including automatic bypassing 
of transactions which repeatedly cause errors, 

• Transaction selection for specified transactions to be performed 
within an I/O request, 

• Clearing of the Bypass for all transactions on the network, 

• Transaction selection for all transactions used by a particular 
function, 

• Updating a network partitioning definition, and 

• Switching the root link(s) (I/O Interface (4.1.3)) connecting an 
I/O network to a processing site. 

The above services are implemented by the following subprocesses: 

(1) I/O Request Processing 

(2) Chain Processing 

(3) I/O Interface 

(4) GPC I/O Network Manager Support 

I/O Request Processing (4.1.1) handles all requests and coordinates 
services affecting one or more networks. 

Each instance of Chain Processing (4.1.2) implements services as they 
apply to a particular I/O network at a processing site. It also 
coordinates the I/O Interfaces (4.1.3) for that I/O network. 

One or more I/O Interfaces (4.1.3) connect a processing site to an 
I/O network. This process implements the actual communication 
between the processing site and the DIUs and/or nodes connected to 
the I/O network as specified by Chain Processing (4.1.2). 

An instance of GPC I/O Network Manager Support (4.1.4) independently 
coordinates the reporting of GPC_Subscr iber_IO_Error_Log information 
to a particular I/O Network Manager (4.2) . 
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Process Name: 
Reference Number: 
Identifier: 


I/O Request Processing 
4.1.1 

IO_Sys tem_Serv i ces . - 
IO_User_Commun i cat i on_Serv i ces . 
IO_Request_Process i ng 
Build: 3 ’ 

Requirements Reference: 3 


Inputs : 

• IO_Data_Base.IO_Request_Def i ni t ion 

• GPC_Subscr i ber_Command from System Manager (1.) 

• IO_Request_Parameter from Application Function 

• Manager IO_Request_Parameter from I/O Network Manager 
(4.2) 

• Reconf i gur at ion_Report from I/O Network Manager (4.2) 

• Chain_Queue from Chain Processing (4.1.2) 

• Chai n_Data_And_Status from Chain Processing (4.1.2) 


Outputs : 

• Wait_Request to Local Operating System 

• IO_Request_Data_And_Status to Application Functions 

• Manager_IO_Request_Data_And_Status to I/O Network Man 
ager (4.2) 

• Chain_Queue to Chain Processing (4.1.2) 


Notes : 


There is one instance of this process for each 
instance of I/O User Communication Services (4.1). 


Description: 


This process coordinates service requests from I/O Network Managers 
(4.2) and service requests from Application Functions that pertain to 
one or more I/O networks. Each service request is transformed into 
one or more elements on one or more Cha i n_Queue (s) to be processed by 
instances of Chain Processing (4.1.2). Status and data resulting 
from this processing are collected via Chain_Queue and 
Cha i n_Data_And_Status . 


The above processing is accomplished via two subprocesses: 

(1) Request Initiation Processing 

(2) Request Completion Processing 

Request Initiation Processing (4. 1.1.1) transforms service requests 
that are input as IO_Request_Parameter , Manager_IO_Request_Parameter , 
GPC_Subscr iber_Command, or Reconf iguration_Report into elements on 
the appropriate Chai n_Queue (s) . 
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Request Completion Processing (4. 1.1. 2) collects data and status from 
Chain_Queue and Chai n_Data_And_Status inputs and transforms them into 
IO_Request_Data_And_Status and Manager_IO_Request_Data_And_Status . 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Request Initiation Processing 
4.1 .1 .1 

I0_Sys tem_Serv i ces . - 
IO_User_Commun i cat i on_Serv i ces . 
IO_Request_Process i ng . - 
Request_In i t i at i on_Process i ng 
3 


Requirements Reference: POC System I/O Services Functio nal Require- 

ments . section 2, Paragraph 2 and 3 and sec- 
tions 3.1 .4.1 , 3.1 .4.2, 3.1 .4.4.1 , 3.3 


Inputs: 

• IO_Data_Base.IO_Request_Def i ni t ion 

• IO_Request_Parameter from Application Functions 

• GPC_Subscr iber_Command from System Manager (1.) 

• Manager IO_Request_Parameter from I/O Network Manager 

(4.2) 

• Reconf iguration_Report from I/O Network Manager (4.2) 

• Chain_Queue from Request Completion Processing 

(4. 1.1 .2) and Chain Processing (4.1.2) 


Outputs: 


• IO_Request_Data_And_$tatus to Application Functions 

• Wait.Request to Locai Operating System 

• Chain_Queue to Chain Processing (4.1.2) and Request 
Completion Processing (4. 1.1. 2) 

• Manager_IO_Request_Data_And_Status to I/O Network Man- 
ager (4.2) 


Notes: Processing by this process should not lock out proc- 
essing by other processes (such as Sequencer 

(4.1 .2.1.1) and Request Completion Processing 

(4.1 .1.2)) due to accesses to Chain_Queue data. This 
may be implemented by semaphores, a monitoring proc- 
ess, or some other mechanism to control access to 
Chain_Queue data. 


Description: 


This process transforms each request for service into elements on one 
or more Chai n_Queue (s) . Services are then implemented as the ele- 
ments from the Chai n_Queue (s) are processed by their corresponding 
Chain Processing (4.1.2) processes. Each Chain_Queue corresponds to 
an instance of Chain Processing (4.1.2). Each instance of Chain Pro- 
cessing corresponds to a specific I/O network. 


Communication with nodes and/or DIUs Is requested via 
IO_Request_Parameter or Manager_IO_Request_Parameter . Either input 
specifies the same information. A Service_Ident i f i er indicates the 
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request is an IO_Service_Request. An IO_Request_Identi f i er indicates 
a specific IO_Request_Def ini tion within the IO_Data_Base. This defi- 
nition directs how IO_Request_Data from IO_Request_Parameter or 
Manager_IO_Request_Parameter should be distributed between one or 
more Transact ion_Queue_Elements, hence, how the data should be dis- 
tributed between the transactions performed on each I/O network. The 
definition also indicates the Cha?n_Queue in -which each element 
should be inserted (one Chain_Queue per element). Each element is 
inserted into its Chain_Queue according to the priority implied by 
the input (Manager_IO_Request_ Parameter having a higher priority than 
IO_Request_Parameter) or according to the IO_Request_Pr ior i ty explic- 
itly specified by IO_Request_Parameter . The definition also speci- 
fies whether a Wait_Request should be made for the process which made 
the request or the chain completion indicators for the request should 
be initialized to "Not_F i ni shed_Yet" . (If the process is caused to 
wait, it is released by Request Completion Processing (4.1 .1 .2) when 
the request is completed.) 

Transaction selection is also requested via IO_Reques ^Parameter or 
Manager_IO_Request_Parameter . A Service^ Identif ier indicates the 
request is a Transaction_Selection_Request. An IO_Request_Identi f ier 
indicates a specific IO_Request_Def ini tion within the IO_Data_Base. 
Selection - .Queue_Elements are constructed from the Chai n_Ident i f i er s , 
Transact ion_Ident if ier s, and Selection components of the input and 
inserted into Chain.Queues as directed by the IO_Request_Def i ni ti on. 
These elements are assumed to have a priority higher than the priori- 
ty of their corresponding I0_Servi ce_Request, i.e., Chain_Queue ele- 
ments created for a Transact ion_Se I ection_Request will always precede 
elements created for a IO_Service_Request that has the same 
Reques t_Ident i f i er . 

Clearing Bypass for all transactions on a network is requested via 
the Reconf iguration_Report input. This will be implemented by mark- 
ing a chain of transactions for clearing, the Bypass for each trans- 
action to be cleared the next time the chain is executed. The 
Network_Identif i er specified by this input indicates the Chain_Queue 
on which to place the Bypass_Clear_Queue_Element specified by the 
input. This element specifies that all transactions on this network 
should have their error counts and bypasses initialized to zero and 
"No", respectively. 

Transaction selection for all transactions used by an Application 
Function may be requested either via IO_Request_Parameter or via 
GPC_Subscr iber.Command. IO_Request_Parameter specifies a 
Servi ce_Identi f ier value of "Appl ication_Ini tial ization_Request". 
Either input specifies a Function_Identif ier specifying which func- 
tion is to be initialized. Function_Identif ier indicates a group of 
IQ_Request_Def ini t ions in IO_Data_Base. These definitions provide 
the Selection_Defaul ts used to construct Selection_Queue_Elements for 
each I/O network accessed by the Application Function and to place 
these elements on the correct Cha i n_Queues . 

Updates to network partition definitions are requested via 
Manager_IO_Request_Parameter . The Servi ce_Ident i f ier component spec- 
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ifies Parti tion_llpdate_Request. The Network_Identi f ier component 
specifies which Chain_Queue should receive the 
Network_Parti tion_Queue_Element which is constructed from the 
Root_Link_Identif iers, Node_Identif iers, and DIU_Identi f i ers listed 
in the remainder of the input that specify which Nodes and DIUs may 
be accessed via which root links. 

Root link switching is requested via Manager_IO_Request_Parameter . 
The Service_Identif ier component specifies Root_link_Control_Request. 
The Network_Identif ier component specifies which Chain_Queue should 
receive the Root_Link_Queue_Element, i.e., for which network the root 
link should be switched. The queue element specifies whether or not 
automatic root link switching should be inhibited and which root 
links should be used according to the Inhibit and 
Root_Link_Identif ier components of the input. 
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Figure 3-1. Request Initiation Processing 
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Process Name: 
Reference Number: 
Identifier: 


Bui id: 


Request Completion Processing 
4.1 .1 .2 

IO_System_Services.- 
IO_User_Commun i cat i on_Serv i ces- 
IO_Request_Process i ng . - 
Reques t_Comp 1 et i on_Process i ng 
3 


Requirements Reference: PQC System I/O Services Functional Require- 

, sections 3.1 .4.1 . 3.1 .4*2 i 3.1 .4.4.1 


Inputs: 

• IO_Data_Base.IO_Request_Def ini tion 

• Cha i n_Oata_And_Status from Chain Processing (4.1.2) 

• Chain_Queue from Request Initiation Processing 
(4.1 .1.1) and Chain Processing (4.1.2) 

Outputs: 

• Wait_Request to Local Operating System 

• IO_Request_Data_And_Status to Application Functions 

• Manager_IO_Request_Data_And_Status to I/O Network Man- 
ager (4.2) 

• Chain_Queue to Request Initiation Processing (4.1 .1.1) 
and Chain Processing (4.1.2) 


Notes: Processing by this process should not lock out proc- 

essing by other processes (such as Request Initiation 
Processing (4.1 .1.1) and Sequencer (4.1 .2.1.1)) due to 
accesses and references to Chain_Queue data. This may 
be implemented by semaphores, a monitoring process, or 
some other mechanism to control access to Chain_Queue 
data. 


Description: 


This process completes processing of requests for communication to 
Nodes (4.1.5) and DIUs by collecting data and status and releasing 
processes that were placed on the local wait queue at the request of 
Request Initiation Processing (4.1 .1.1). It is initiated by a signal 
from Chain Processing (4.1.2). 


When Chain_Data_And_$tatus is received, the element at the top of the 
corresponding Chain_Queue is examined. The Chain_Ident i f i er is used 
to identify the IO_Request_Def ini tion that specified the element for 
Request Initiation Processing (4. 1.1.1). 


If the IO_Request_Def i ni t ion indicates that the original request was 
a manager I/O request for service: 
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• Manager_IO_Request_Data_And_Status is updated to reflect the val 
ues of Chai n_Data_And_Status, 


• Manager_IO_Request_Data_And_Status is updated to reflect the val- 
ues of Root_Li nk_Status from the Chain_Queue element, 

• The element is removed from the Chain_Queue, 

• If the Network Manager (4.2) making the request was placed on the 
local wait queue at the request of Request Initiation Processing 
(4.1 .1.1), this process issues a Wait_Request to the Local Oper- 
ating System to remove the manager from the local wait queue. 
Otherwise, the manager can determine that the I/O request has 
completed by examining the status value for the chain in 
Manager_IO_Request_Data_And_Status . 

If the IO_Request_Def i ni tion indicates that the original request was 

from an Appl ication-Runction: 

• The element is removed from the Chain_Queue. 

• IO_Request_Data_And_Status is updated with the values of 
Chai n_Data_And_Status, as specified by the IO_Request_Def ini tion. 

• If function was placed on the local wait queue at the request of 
Request Initiation Process i ng • (4.1 .1 .1 ) , the process determines 
whether or not all chains for the I/O request have been proc- 
essed. If they have, the process requests that the Application 
Function be released from the local wait queue by issuing a 
Wait_Request to Local Operating System. Otherwise, the request- 
ing function can determine that the chain has completed by exam- 
ining the status value for the chain in 
IO_Request_Data_And_Status . 



Process Name: 
Reference Number: 
Identifier: 


Build: 


Chain Processing 
4.1 .2 

IO_System_Servi ces 
IO_User_Commun i cat i on_Serv i ces- 
Chain_Processing 
3 


Requirements Reference: (See subprocesses) 


Inputs: 

• IO_Data_Base. IO_Request_Def i n i t i on . I0_Cha i n_Def i n i t i on 

• Chain_Queue from I/O Request Processing (4.1.1) 

• End_Of_Chai n_Status from I/O Interface (4.1.3) 

• Input_Packet from I/O Interface (4.1 .3) 

• Transaction_Conf iguration_Data_Base from I/O Interface 
(4.1 .3) 

• Current_Network_Part i t ion_Def i ni t ion from I/O Interface 
(4.1.3) 


Outputs: 

• Local_IO_Status to Local System Services (3.) 

• Chain_Data_And_Status to I/O Request Processing (4.1.1) 

• Chain_Queue to I/O Request Processing (4.1.1) 

• Chai n_Ini t iat ion_Command to I/O Interface (4.1.3) 

• Current_Network_Part i t ion_Def i n i t i on to I/O Interface 
(4.1 .3)" 

• OutpUt_Packet to I/O Interface (4.1 .3) 

• Transact ion_Configur at ion_Data_Base to I/O Interface 
(4.1.3) 

• GPC_Subscr iber_IO_Error_Log to GPC I/O Network Manager 
Support (4.1 .4) 


Notes: An instance of this process must exist at each proc- 

essing site for each I/O network that is accessible at 
the processing site. 


Queue Processing (4. 1.2.1) must not interrupt Chain 
Interface (4.1 .2.3) . 


End Of Chain Monitor (4.1 .2. 2. 2.1) may interrupt Queue 
Processing (4. 1.2.1). 


Descr i ption: 


This process sequentially processes the elements from the Chain_Queue 
corresponding to its I/O network. Each element initiates one of the 
following services on the network: 

• Communication with nodes or DIUs including automatic bypassing of 
transactions which repeatedly cause errors, 
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• Selection of which transactions to perform within a chain of 
transactions on the network, 

• Clearing of Bypass for all transactions in selected chains on the 
network, 

• Updating the network partitioning definition, and 

• Switching the root link(s) (I/O Interface (4.1.3)) connecting the 
I/O network to a processing site. 

The above services are implemented by three subprocesses: 

(1) Queue Processing 

(2) Chain Completion Processing 

(3) Chain Interface 

Queue Processing (4. 1.2.1) initiates all requests for service on a 
particular I/O network. It implements selection of transactions, 
clearing of Bypass for transactions, and updates to the 

Current_Network_Part i t ion_0ef i n i t ion. It initiates Chain Completion 
Processing (4.1 .2.2) and Chain Interface (4. 1.2. 3) to- implement com- 
munication with nodes and DIUs, signaling I/O Request Processing 
(4.1.1) when the communication processing has been completed. It 
coordinates processing between Chain Completion Processing (4.1 .2.2) 
and Chain Interface (4. 1.2. 3) to implement the switching of root 
1 i nks. 

Chain Completion Processing (4.1 .2.2) monitors the I/O Interfaces 
(4.1.3) to complete the processing of a chain of transactions, 
records errors that occurred during communications, and decides when 
errors indicate that a root link should be switched. 

Chain Interface (4.1 .2.3) interfaces Queue Processing (4.1 .2.1) with 
I/O Interface (4.1.3) to initiate chains of transactions on the net- 
work and to switch root links. 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Queue Processing 
4.1 .2.1 

IO_System_Serv i ces . - 
IO_User_Commun i ca t i on_Serv i ces- 
Cha i n_Process i ng . Queue_Process i ng 
3 


Requirements Reference: (See subprocesses) 


Inputs: 

• Cha i n_Queue 

• Current_Network_Parti tion_Def ini tion 

• IO_Data_Base . IO_Request_Def i n i t i on . IO_Cha i n_Def i n i t i on 

• IO_Data_Base.Limi ts_Def i ni tion 

• Chain_Completion_Status from Chain Completion Process- 
ing (4.1 .2.2) 

• T ransact i on_Conf i gurat i on_Data_Base 

Outputs: 

• Cha i n_Queue 

• Local _IO_Status to Local System Services (3.) 

• Current_Network_Parti tion_Def i ni tion 

• Output_Packet 

• Transact ion_Confj gurat ion_Data_Base to I/O Interface 
(4.1 ."3) and Chain Completion Processing (4.1 .2.2) 

• Chain_Timeout_Value to Chain Completion Processing 
(4. 1.2. 2) 

• Activate_Chain to Chain Interface (4.1 .2.3) 

• Root_Link_Command to Chain Interface (4.1 .2.3) 


Notes: The Activate_Chain and Root_Link_Command data flows 

must be nonobtrusive (asynchronous) to Chain Interface 
(4.1 .2.3) . In other words, the implementation should 
not interrupt this process. 

Description: 


This process implements the following services for a single I/O net- 
work: 


• Selection of which transactions to perform within a chain of 
transactions on the network, 

• Clearing of Bypass for all transactions in selected chains on the 
network, and 

• Updating the network partition definition. 

It also initiates the following services: 

• Communication with nodes or DIUs, coordinating with Chain Inter- 
face (4. 1.2. 3) and Chain Completion Processing (4. 1.2. 2) to 
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implement automatic retries and automatic switching of root links 
via this service. 

• Switching the root 1 i nk (s) (I/O Interface (4.1.3)) connecting the 
I/O network to a processing site. 

The above is accomplished via six subprocesses: 

(1) Sequencer 

(2) Chain Initiation 

(3) Root L i nk 

(4) Bypass Clear 

(5) Transaction Selection 

(6) Network Partition 

Sequencer (4. 1.2. 1.1) invokes the other subprocesses according to the 
top element found in Chain_Queue. It also invokes Root link 
(4. 1.2. 1.3) when requested by Chain Completion Processing (4.1 .2.2) 
for automatic root link switching and invokes Chain Initiation 
(4. 1.2. 1.2) for automatic retry of communi cations to nodes or DIUs. 

Chain Initiation (4.1 .2.1 .2) initiates communications to nodes or 
DIUs and clears the Bypass for all transactions in chains that are 
marked for bypass clearing .in the 

Tr ansae t i on_Conf i gur at i on_Data_Base . 

Root Link (4.1 .2.1 .3) chooses root links and initiates root link 
swi tching. 

Bypass Clear (4. 1.2. 1.4) marks chains of transactions for clearing of 
their bypass states upon the next occurrence of the chain. 

Transaction Selection (4. 1.2. 1.5) sets up the selection of trans- 
actions to be performed in specified chains. 

Network Partition (4.1 .2.1.6) updates 

Current_Network_Part i t ion_Def i ni tion. 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Sequencer 
4.1 .2.1 .1 

IO_System_Services .- 
IO_User_Commun i cat i on_5erv i ces . 
Cha i nJ»rocess i ng . - 
Queue_Process i ng . - 
Sequencer 
3 


Requirements Reference: 


ments . section 2, paragraph 3 and section 
3.1 .5 


Inputs: 

• Cha i n_Queue 

• IO_Data_Base.IO_Request_Def ini t ion.I0_Chai n_0ef i ni tion 

• IO_Data_Base.Limi ts_Def ini tion 

• Chain_Completion_Status from Chain Completion Process- 
ing (4.1 .2.2) 

• Root_Link_Status from Root Link (4.1 .2.1 .3) 

Outputs: 

• Chain_Queue 

• Local _IO_Status 

• Transact ion_Queue_E I ement to Chain Initiation 

(4.1 .2.1 .2) 

• Root_Link_Queue_Element to Root Link (4.1 .2.1 .3) 

• Bypass_Clear,_Queue_Element to Bypass Clear (4.1 .2.1 .4) 

• Selection_Queue_Element to Transaction Selection 

(4.1 .2.1 .5) 

• Network_Parti tion_Queue_Element to Network Partition 
(4.1 .2.1 .6) 

Notes: Processing by this process should not lock out proc- 

essing by other processes (such as Request Initiation 
Processing (4.1 .1.1) and Request Completion Processing 
(4.1 .1.2)) due to accesses and references to 
Chain.Queue data. This may be implemented by sema- 
phores, a monitoring process, or some other mechanism 
to control access to Chain_Queue data. 

Description: 

This process initiates the following services for its I/O network: 

• Communication with nodes or DIUs, 

• Switching the root link(s) (I/O Interface (4.1.3)) connecting the 
I/O network to a processing site, 

• Clearing the Bypass for all transactions in selected chains on 
the network. 
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• Selection of which transactions to perform within a chain of 
transactions on the network, and 

• Updating the network partition definition. 

No service is initiated until the previous service has completed. 
When no service is in progress and the Chain_Queue is not empty, the 
top element of the queue is selected to determine which service to 
initiate. The element also indicates the parameters to be used to 
implement the service. 

Communication to Nodes or DIUs is initiated by passing the 
Chain_Queue element as a Transact i on_Queue_E 1 ement to Chain Initi- 
ation (4. 1.2. 1.2). The element is not removed from Chain_Queue by 
this process. (It is removed by Request Completion Processing 
4.1 .1 .2 after the service is completed.) Completion of the chain of 
transactions is indicated by Chain_Completion_Status which has three 
possible values (see also End of Chain I/O Error Processing 
(4.1 .2. 2. 2. 2)) : 


"Next_Chain" indicates that processing is completed. The process 
sets the Chai n_Complete data item in the Chain_Queue ele- 
ment to "Cha incomplete". If the communication request was 
from a Network Manager (as indicated IO_Chai n_Def i n i t i on 
when indexed by the Chai n_Identi f ier in the Chain_Queue 
element), the Root_Link_Identif iers for the currently 
active root links are added to the Chain_Queue element. 
(This is why the element is not removed. It must remain on 
the Chain_Queue for outputting data items to Request Com- 
pletion Processing 4.1 .1 .2.) In any case, processing halts 
until a new element appears at the top of the Chain.Queue 
(See Request Completion Processing (4.1 .1.2)). 

"Swi tch_Root_Unk_And_Next_Chain" indicates that, before completing 
processing, the root link(s) should be switched. If the 
communication request came from an I/O Network Manager 
(4.2) (see "Next_Chain" above) and the 

Manager_IO_Request_Parameter (Root_Li nk_Contro1_Request) 
indicates "Inhibi t_Swi tching", the switch request is treat- 
ed as if it were "Next_Chain". Otherwise, the root link is 
switched as described below and processing of the chain is 
completed by assigning Root_li nk_Identi f iers and 

Chain_Compete (see the description of "Next_Chain", above). 

There are three types of internal counters for root link 
switching: onq to count how many times a particular root 

link is switched, one to count how many times all the root 
links for a partition have been switched as a whole, and 
one to count how may times a chain has been retried. The 
retry counter is always initialized to zero when a new com- 
munication is requested via a Chain.Queue element. Each 
time a root link is to be switched, one or more counters 
are incremented by one. 
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If the switch will cause a root link counter to exceed 
Swi tch i ng_Limi t .Sing1e_Li nk_Log_Limi t (found in 

Limits_Def inition) , this fact is logged with the current 
time and Cha incident if ier, the counter is initialized to 
zero. In this case, the root link will be switched. Proc- 
essing continues as described in the next paragraph. 

If the switch will cause a group counter to exceed 
Switching_Limit.Rotation_Log.J.imit (also found in 
Limi ts_Def ini tion) , this fact is logged with the current 
time and Chain_Identif ier, the counter is initialized to 
zero. In this case, the root link will be switched. Proc- 
essing continues as described in the next paragraph. 

If there is another I/O Interface (4.1.3) to use for the 
given partition, the switch is initiated via 
Root_Link_Queue_Element which indicates the partition of 
the I/O network which is to have its root link switched. 
(The actual switch- does not occur if there is no alterna- 
tive root link; there is no reason to switch from one root 
link to itself.) After the root link is switched, the new 
Root_Link_Identif ier value indicated by Root_Link_Status is 
stored. 

"Swi tch_Root_L i nk_And_Repeat_Cha 1 n" indicates that the root link 
should be switched and the same communication request 
attempted again. (This status may be caused by the failure 
of the I/O Interface to win a contention.) 

If the communication request came from a Network Manager 
(4.2) (see "Next_Chain n above) and the 

Manager_IO_Request_Parameter (Root_L i nk_ControI_Request) 
indicates "Inhibi t_Swi tch i ng", the root link is not 

. switched, the chain is not repeated, and the Chain.Queue 

element is assigned values for Root_Li nk_Ident i f iers and 
Chai n_Compl ete (see "Next_Cha i n" , above). 

Otherwise, the retry counter is incremented by one. If the 
retry counter exceeds Swi tching_Limi t.Retry_Limi t (located 
in Limits_Def inition) , the root link is not switched, the 
chain is not repeated, and the Chain.Queue element is 
assigned values for Root_Link_Identif iers and 
Chain_Compl ete (see "Next_Chain", above). 

Otherwise, processing to switch the I/O Interface (4.1.3) 
continues as described in "Swi tch_Root_Link_And_Next_Chai n" 
above . 

After the retry counter is incremented and the switch has 
been performed (or skipped due to the lack of an alterna- 
tive root link), the chain is repeated reissuing the 
Transact i on_Queue_£ lement. This causes a new value to be 

returned for Chain_Completion_Status. 
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Explicit root link switching is initiated by passing on a 
Root_Link_Queue_E lament. Additional processing includes storing the 
Root_Link_Identif ier indicated by Root_Li nk_Status and removing the 
element from the Chain.Queue. 


Marking of chains of transactions for bypass clearing is 
passing on a Bypass_Clear_Queue_Element. Additiona 
includes removing the element from the Chain_Queue. 


initiated by 
process i ng 


Selection of transactions to be performed within a chain is initiated 
by passing on a Selection_Queue_Element. Additional processing 
includes removing the element from the Chain_Queue. 


Updating of the current network partition definition is initiated by 
passing on a Network_Part i t ion_Queue_E lement . Additional processing 
includes removing the element from the Chain_Queue. 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Chain Initiation 
4. 1.2. 1.2 

I0_Sys tem_Serv i ces . - 
IO_User_Commun i cat i on_Serv i ces . - 
Chain_Process i ng.- 
Queue_Process i ng . - 
Chain_Ini ti at ion 
3 


Requirements Reference: POC System I/O Se rvices Functional Require- 

ments . section 3. 1.4. 2 paragraph 1,. section 
3.3.3 


Inputs: 

• I0_Data_Base.I0_Request.J3ef ini tion.I0_Cha i n_Def i ni tion 

• T ransact i on_Conf i gurat i on_Data_Base 

• Transact i on_Queue_E lement from Sequencer (4. 1.2. 1.1) 

Outputs: 

• Transact i on_Conf i gurat i on_Data_Base 

• Output_Packet 

• Chain_Timeout_Value to Chain Completion Processing 
(4.1 .2.2) 

• Activate_Chain to Chain Interface (4.1 .2.3) 


Notes: The Activate.Chain data flow must be nonobtrusive 

(asynchronous) to Chain Interface (4. 1.2. 3). In other 
words, the implementation should not interrupt this 
process . 


Description: 


This process sets up the chain of transactions to be communicated on 
the I/O network. It initializes an Output_Packet for each trans- 
action in the chain with data from Transact ion_Queue_E lement. The 
number of transactions and packets and their identities are provided 
by I0_Chain_Def ini tion. 

If the Transact ion_Confi gurat ion_Data_Base indicates that the chain 
is marked for bypass clearing (Bypass_Clear equals "Clear"), this 
process clears the Bypass (sets Bypass to "No") and zeros the 
Transact ion_Error_Counter for each transaction in the chain. Both 
items are part of the Transact ion_Confi gurat ion_Data_Base. 


Finally, the process outputs the Chain_Timeout_Va1ue (from 
I0_Chain_Def ini tion) to begin Chain Completion Processing (4.1 .2.2) . 
Chai n_Timeout_Value includes Chai n_Ident i f i er . This process also 
outputs Chain_Identif ier via Activate_Chain to begin the Chain Inter- 
face (4.1 .2.3) process. 
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Process Name: 
Reference Number: 
Identifier: 


Root Link 
4.1 .2.1 .3 

IO_System_Servi ces . - 
IO_User_Commun i cat i on_Serv i ces . - 
Cha i n_Process i ng. - 
Queue_Process i ng . - 
Root_Link 
Build: 3 

Requirements Reference: PQC Syst em I/O Services Functional — Requi re~ 

ments . section 4.1 


Inputs: 

• Root_L i nk_Queue_E 1 ement from Sequencer (4.1 .2.1.1) 

• Cur rent_Network_Part i tion_Def ini tion from I/O Network 
Manager (4.2) 


Outputs: 


Notes: 


Root_L i nk_Command to Chain Interface (4.1 .2.3) 

Root_L i nk_Status to Sequencer (4. 1.2. 1.1) 

The Root_L i nk_Command data flow must be nonobtrusive 
(asynchronous) to Chain Interface (4.1 .2.3) ^ In other 
words, the implementation should not interrupt this 
process. 


Description: 


This process computes how to switch root links, i.e., which I/O 
Interface (4.1.3) to enable and which I/O Interface to disable, and 
implements the switch via Chain Interface (4.1 .2.3) . The computation 
is based on the the Root_Li nk_Ident i f ier (s) specified by 
Root_L i nk_Queue_E 1 ement or a rotating choice of one of the alternate 
root links specified by the Current_Network_Parti tion_ Def ini tion. 
The Root_L incident if ier (s) selected is communicated to Sequencer 
(4.1 .2.1.1) via Root_Link_Status. 



Process Name: Bypass Clear 

Reference Number: 4.1 .2.1 .4 

Identifier: IO_System_Services.- 

IO_User_Commun i cat i on_Serv i ces . - 
Cha i n_Process i ng . - 
Queue_Processing.- 
Bypass.Clear 
Build: 3 

Requirements Reference: PQC System I/O Se rvices Functi 

ments. section 3.3.3 


Inputs : 


• Bypassed ear_Queue_Element from Sequencer 

Outputs: 

• T ransact i on_Conf i gur at i on_Data_Base 

Notes: None 

Description: 

This process marks the Bypass_Clear 
Transact ion_Configuration_Data_Base for each chain 
Cha incident? f ier in 8ypass_C 1 ear_Queue_E 1 ement . 


onal Require 


(4.1 .2.1 .1) 


flag in 

indicated by 
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Process Name: Transaction Selection 

Reference Number: 4. 1.2. 1.5 

Identifier: IO_System_Servi ces .- 

IO_User_Commun i cat i on_Serv i ces . - 
Cha i n_Process i ng . - 
Queue_Pr ocess i ng . - 
Transact ion_Se lection 
Build: 3 

Requirements Reference: PQC System I/O Services Functional Require- 

ments. section 3.3.2 


Inputs: 

• Selection_Queue_Element from Sequencer (4. 1.2. 1.1) 

Outputs: 

• Transact i on_Conf i gurat i on_Data_Base 

Notes: None 

Description: 

This process latches the Selection indicators in 
Transact ion_Confi gurat ion_Data_Bas« to "Select" or "Skip" as speci- 
fied for each transaction specified in Transact ?on_Queue_Element. 


The operation 

of latch i 

i ng a 

transaction 

Sel 

ection 

i ndicator 

to 

"Select" also 

causes 

the 

Bypass 

to 

be 

cleared and 

the 

Transaction_Error_Counter 

to be 

zeroed. 

Both 

of 

these 

i terns a 1 so 

are 


i n Transact ion_Conf i gurat ion_Data_Base. 
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Process Name: 
Reference Number: 
Identifier: 


Bui Id: 


Network Partition 
4,1 .2.1 .6 

IO_System_Servi ces .- 
IO_User_Commun i cat i on_Serv i ces . - 
Chain_Processi ng.- 
Queue_Process i ng . - 
Network_Parti tion 
3 


Requirements Reference: PQC System I/O Services Functional Require 

ments . section 4.2.1 .2 


Inputs: 

• 

Network_Parti tion_Queue_E1ement from Sequencer 

(4.1 .2.1.1) 

Outputs: 

• 

Current_Network_Parti tion_Def ini tion to Root Link 

(4.1 .2.1.3) and I/O Interface (4.1.3) and Chain Com- 
pletion Processing (4. 1.2. 2) 

Notes: 


None 

Description: 

. 

This process updates the Current_Network_Part i t ion_Def i ni tion. 
Network_Parti tion_Queue_Element provides the list new assignments of 


nodes and DIUs to I/O Interfaces (4.1.3). 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Chain Completion Processing 
4.1 .2.2 

IO_System_Services.- 

IO_User_Commun i cat i on_$erv i ces . - 

Cha ? n_Process i ng . - 

Cha i n_Compl et i on_Process i ng 

3 


Requirements Reference: (See subprocess descriptions below.) 


Inputs: 


• Current_Network_Parti tion_Def ini tion 

• End_0f_Cha in_Status 

• Input_Packet 

• IO_Data_Base.IO_Request_Def i ni t ion.I0_Cha i n_Def i ni ti on 

• I0_Data_Ba*®- Limi ts_Def i ni t ion 

• Transact ion_Conf i gurat ion_Data_Base 

• Chai n_Timeout_Vaiue from Queue Processing (4. 1.2.1) 


Outputs: 


Notes : 


• GPC_Subscr iber_IO_Error_Log 

• Transact i on_Conf i gurat i on_Data_Base 

• Chai n_Data_And_Status to I/O Request Processing (4.1.1) 

• Chain_Completion_Status to Queue Processing (4. 1.2.1) 

This process may be interrupted by either the Chain 
Interface (4.1 .2.3) process or an internal timer 
i nterrupt. 


Description: 


This process logs errors that occur during a communication service, 
produces the data and status resulting from the service, and indi- 
cates to Queue Processing (4. 1.2.1) when errors indicate that a root 
link should be switched and when a communication attempt has termi- 
nated. 


The above is accomplished via two subprocesses: 

(1) Data/Status Processing 

(2) Chain Status Processing 

Data/Status Processing (4.1 .2.2.1) collects data and status for each 
transaction to create Chain_Data_And_Status. 

Chain Status Processing (4.1 .2.2.2) records error information, com- 
putes when to automatically bypass transactions, controls Data/Status 
Processing (4. 1.2. 2.1), and notifies Queue Processing (4. 1.2.1) of 
the Chain_Completion_Status. 
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Process Name: 
Reference Number: 
Identifier: 


Bui Id: 


Data/Status Processing 
4.1 .2.2.1 

IO_Sy s tem_Serv i ces . - 

IO_User_Commun i cat i on_Serv i ces . - 

Cha i n_Process i ng . - 

Cha i n_Comp 1 et i on_Process i ng . - 

Data_Status_Process i ng 

3 


Requirements Reference: PQC System, I/Q,. S.crvi.ces.-Funct ional Require- 

ments . section 3.2.2 


Inputs: 

• Input-Packet 

• Transact i on_Conf i gurat i on_Data_Base 

• Current-Network-Part i tion_Def i ni t ion 

• IO_Data_Base.IO_Request_Def i ni t i on.I0_Chai n_Def i ni t ion 

• Cha i n_Ident i f i er from Chain Status Processing 

(4.1 .2.2.2) 

• Transaction-Status from Chain Status Processing 

(4.1 .2.2.2) 

• Chain_Status from Chain Status Processing (4.1 .2.2.2) 

Outputs: 


• Cha i n_Data_And— Status to I/O Request Processing (4.1.1) 

• Packet_Status to Chain Status Processing (4. 1.2. 2. 2) 

• Chain_Transaction_Status to End Of Chain I/O Error Pro- 
cessing (4.1 .2. 2. 2. 2) 


Notes.: None 


Description: 


This process collects data and status for each transaction of a chain 
to create Chain_pata_And_Status. It is initiated by Chain Status 
Processing (4.1 .2.2.2). 


Each Input.Packet is made source congruent before it is used. Source 
congruency is performed based on the 
Current-Network-Partition-Definition such that, for each transaction, 
an Input-Packet is selected from the channel connected to the I/O 
Interface (4.1.3) that actually performed, or attempted to perform, 
the transaction. This process produces Packet-Status from 
Input-Packet. 


Frame_Protocol-Error_Indicator and Transact ion_Timeout_Indicator are 
copied directly from Input-Packet. Interface-Status. 
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Incorrect_Message_Length_Indi cator is set if 
Input_Packet.Frame_Length does not match the expected value of 
Frame_Length in IO_Data_Base for the transaction. 

Address_Mi smatch_Indi cator is set if Input_Packet.Network_Address 
does not match the expected value of Network_Address in IO_Data_Base 
for the transaction. 

For Response Frames from OIUs, Encoded_Address_Indi cator is set if 
the values of Input_Packet.Network_Address and the Encoded_Address 
(found in Input_Packet.Data) do not correspond. 

Finally, the Res i dual _B i t_Count_Indi cator is set if 
Input_Packet .Interf ace_Status .Res i dual_B i t_Count does not match the 
expected value of Residua1_Bi t_Count in IO_Data_Bas® for the trans- 
action. 

A Transaction_Status is received for each Packet_Status. The data 
from each Input_Packet i-s- combined with the Bypass.Indi cator and 
Comfaul t_Indi cator indicated by Transact ion_Status and collected in 
Cha i n_Data_And_Status . 

This process uses Chain_Status plus error information about each 
transaction in the chain to form Chai n_Transaction_Status . 
Cha i n_Transact i on_Status indicates whether any transactions were per- 
formed; and if there were, whether there were no errors in the chain, 
at least one error, or errors in all transaction in the chain. 
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Process Name: Chain Status Processing 

Reference Number: 4. 1.2. 2. 2 

Identifier: IO_System_Services.- 

IO_User_Commun i cat i on_Serv i ces . - 
Cha i n_Process i ng . - 
Cha i n_Comp 1 et i on_Process i ng . - 
Cha? n_Status_Process i ng 
Build: 3 


Requirements Reference: 


ments . section 3.1 .4.4.2, 3.2.2, 5. 1.1.1, 

and 5.1 .1 .2 


Inputs: 

• Current_Network_Par t i tion_Def ini t ion 

• End_Of_Chai n_Status 

• IO_Data_Base.IO_Request_Def i ni t i on.IO_Cha i n_Def i ni t i on 

• IO_Data_Base.Lim? ts_Def ini tion 

• T ransact i on_Conf i gurat i on_Data_Base 

• Chain_Timeout_Value from Queue Processing (4. 1.2.1) 

• Packet_Status from Data/Status Processing (4.1 .2.2.1) 

• Cha in_Tr ansae tion_Status from Data/Status Processing 

(4. 1.2. 2.1) 

Outputs: 

• GPC_Subscr iber_IO_Error_Log 

• Transact i on_Conf i gurat i on_Oata_Base 

• Chain_Completion_Status to Queue Processing (4. 1.2.1) 

• Chain_Identif ier to Data/Status Processing (4.1 .2.2.1) 

• Transact ion_Status to Data/Status Processing 

(4.1 .2.2.1) 

Notes: None 

Description: 

This process controls Data/Status Processing (4.1 .2.2.1), records 
error information for a chain of transactions, computes when to auto- 
matically bypass transactions, and notifies Queue Processing 

(4. 1.2.1) of the Chain_Completion_Status. 

The above is implemented via two subprocesses: 

(1) End of Chain Monitor 

(2) End of Chain I/O Error Processing 

End of Chain Monitor (4.1 .2. 2. 2.1) monitors End_Of_Chain_Status to 
determine when a chain of transactions has been completed and assures 
that this data is source congruent. 
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End of Chain I/O Error Processing (4.1 .2. 2. 2. 2) implements the 
remainder of this process when prompted by End of Chain Monitor 
(4.1 .2. 2. 2.1) . 
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Process Name End Of Chain Monitor 

Reference Number: 4. 1.2. 2. 2.1 

Identifier: IO_System_Services.- 

IO_User_Commun i cat i on_Serv i ces . 

Cha i n_Process i ng . Cha i n_Comp 1 et i on_Process i ng . 
Cha i n_Status_Proce$s i ng . End_Of_Cha i n_Mon i tor 
Build: 3 


Requirements Reference: 


mfiDl£t section 3.2.2 


Inputs: 

• Chai n_Timeout_Va1ue from Queue Processing (4. 1.2.1) 

• End_Of_Chai n_Status from I/O Interface (4.1.3) 

• Current_Network_Parti tion_Def ini tion 

Outputs : 

• Compietion_Status to End Of Chain I/O Error Processing 
(4.1 .2. 2. 2. 2) 

• Chain_Status to Data/Status Processing (4.1 .2.2.1) 

Notes: None 

Description: 

This process generates a vaiue for Compietion.Status based on the 
reception of End_Of_Chai n_Status and the state of an internal timer. 
The timer is started upon the reception of Chain_Timeout_Value. 

End_Of_Chai n_Status is made congruent when it is received. If the 
chain was executed on an I/O network that currently has more than one 
partition, the End_Of_Cha i n_Status values for each partition are used 
to initialize Completion_Status. The congruent version of 
End_Of_Chai n_Status is output as Chain_Status. 

If Cha incomplete occurs while the internal timer is running, the 
timer is turned off and Completion_Status is set to Chain.OK* 

If Chai n_C°mplete occurs when the internal timer is not running, 
Completion_Status is set to Unexpected_Chain_Complete. (This indi- 
cates the detection of a "bus busy" condition while this GPC was not 
using the network.) 

If the internal timer expires before Chain_Ccm»pl®te is received, 
Completion_Status is set to Chai n_Timeout. 

In the case of a partitioned network, this process monitors all 
active partitions for completion. 
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This process also gets Chain_Identi f ier from Chai n.Timeout.Value and 
outputs Cha i n_Identi f i er in Completion_Status. 


DO forever 


Wai t unti 1 Chain. 
Timeout_Value 
received OR 
Cha incomplete 
received 


IF Chain_ \ 
Timeout.Value s 
received / 


WAIT UNTIL 
timeout 
expired OR 
Cha incomplete 
received 


Perform 

End 

Of Chain 

I/O 

Error 


Process i 

ng 

(4.1 .2.2 

.2.2) 


IF timeout \ 
expired 

/ 


Indicate 
Chain.Timeout 
for partition 
not completed 
i n 

Completion. 

Status 


Clear 

pending 

timeout 



Indicate 

Unexpected. 

Cha in.Complete 
in Completion. 
Status 


Indicate 
Chain.OK in 
Completion. 
Status 
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Process Name 
Reference Number: 
Identifier: 


Build: 


End Of Chain I/O Error Processing 
4.1 .2. 2. 2. 2 
IO_System_Services .- 
IO_User_Commun i cat i on_Serv i ces . - 
Cha i n_Process i ng . - 
Chai n.Completion.Processi ng.- 
Chai n_Status_Processi ng. 
End_0f_Cha i n_IO_Error_Process i ng 
3 


Requirements Reference: POC System I/O Se rvices Functional Reauirer 

men ts . section 3.1 .4.4.2$ 3.2.2$ 5.1 .1 .1 $ 

and 5.1 .1 .2 


Inputs: 

• Compl etion_Status from End Of Chain Monitor 

(4.1 .2.2.271) 

• Packet.Status from Data/Status Processing (4.1. 2. 2.1) 

• Transaction_Conf i guration.Data.Base 

• IO_Data_Base. L imi ts.Def i n i t ion 

• IO_Data_Base.IQ_Request._Def ini tion.I0_Chai n_Def i ni t i on 

• Current_Network_Parti tion_Def ini tion 

• Chain_Transaction_Status from Data/Status Processing 
(4.1 .2.2.1) 

Outputs : 

• Transaction_Status to Data/Status Processing 
(4.1 .2.2.1) 

• Chain_Identif ier to Data/Status Processing (4. 1.2. 2.1) 

• Chain_Comp1etion_Status to Queue Processing (4. 1.2.1) 

• Update to Transact ion_Configur at ion_Data_Base 

• Update to GPC_Subscr i ber_I0_Er ror_Log 


Notes: None 


Description: 


This process is initiated by the reception of Completion.Status. 

Based on the values of Comp)etion_Status and 
Chain_Transaction Status, one of four cases is performed. 


(1) When Completion.Status indicates an Unexpected_Chain_Complete, 
case 1 is performed. 

•C 2 ) When Completion.Status indicates Chain.Timeout or 
Chai n.Transaction.Status indicates No.Transactions.Performed, 
case 2 is performed. 
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(3) When Completion_Status indicates Chain_OK and 

Cha i n_Transact i on_Status indicates that at least one transaction 
has an error, case 3 is performed. 

(4) When Completion_Status indicates Chain_OK and 

Chain_Transaction_Status indicates that there were no errors 
among all the performed transactions, case 4 is performed. 

Based on Completion_Status and 

Limi ts_Def i ni t ion. Transact ion_Error_Count_Limi t, the process sets the 
value of Chai n_Complet?on_Status to one of the following: 

"Swi tch_Root_L i nk_And_Repeat_Cha i n" — This is the case in which 
the GPC was unable to win a contention for the network for this 
running of the chain. On the assumption that this indicates a 
root link problem, the chain should be performed on another root 
link. In the event that the reason the GPC could not gain access 
to the network was a network-wide problem, such as a transmitter 
being stuck at one, the assumption is that the Network Manager 
will soon restore the network, and extra root link switches will 
be benign. 

"Swi tch_Root_L i nk_And_Next_Cha i n" — This is the case in which 
the GPC succeeded in winning a contention for the network, but 
was unable to perform any transaction in the chain successfully. 
A root link switch is performed in case the winning of the con- 
tention was allowed by a failure, such as the GPC's receiver for 
the active root link being stuck at zero. However, the chain is 
not retried automatically because it is possible that one or more 
of the errored transactions was an output that was actually per- 
formed, but there was an error on the expected acknowledgment. 
It might be dangerous to repeat the output, so the impetus for 
doing so is left to the caller. 

"Next_Chai n" — This case comprises the situation in which no 
errors were detected, and the situation in which some trans- 
actions had errors and others were error free; that is, the situ- 
ations in which at least one transaction was performed without 
error. In these situations it is most unlikely that a root link 
switch would accomplish anything. 

This process obtains a value of Chai n_Ident i f i er as part of 
Compl eti on_Status to indicate the identity of the chain being proc- 
essed. It also outputs Chain.Identif ier to Data/Status Processing 
(4. 1.2. 2.1). 

Transact ion_Status for each packet is set based on 
Completion_Status.Chain_Status and Packet_Status. This includes set- 
ting the Bypass_Ind icator with the 

Transaction_Configuration_Data_Base. Bypass value for the transaction. 

Transact ion_Configuration_Data_Base components for each transaction, 
including Transaction_Error_Counter , Bypass, and 

Error_Process_Inhibi t, are modified according to their previous val- 
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ues, Bypass_Enabl ed, Packet_Status, and 
Transaction_Error_Counter_Limi t. Bypass_Enabl ed is specified in 
IO_Data_Base for each transaction; it indicates whether or not the 
transaction was defined with the "no transaction bypass" option. 

GPC_Subscr iber_IO_Error_Log is updated according to modifications 
made to Transact ion_Configuration_Data_Base and the values of 
Chain_Completion_Status . 
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DO CASE on 
error status 
information 


Case 1 


Update GPC_ 
Subscriber 
IO_Error_Log 


DO FOR all 
transactions 
that should 
have been 
performed 


Set 

Transact ion. 
Status 


Indicate Switch. 
Root_L i nk_And_ 
Repeat_Chain 


Update GPC. 
Subscriber. 
IO_Error_Log 


Perform 

Case 3 Transaction 

Status/Bypass/ 
Swi tch 

(Figure 3-4 ) 


DO FOR all \ 
transactions 5 
performed / 


Indicate 

Next.Chain 


Clear Transaction. 
Status 

Clear Transaction. 

Error.Counter 
Clear Error. 
Process. 
Inhibit 
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DO FOR each\ 
transaction : 
with error / 


DO FOR each \ 
transaction 
performed 
wi thout 
error / 


I 


j 



Figure 3-5. Mixed Transaction Failures 
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Figure 3-7. Transaction Bypass 
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Process Name: 
Reference Number: 
Identifier: 


Chain Interface 
4.1 .2.3 

I0_Sys tem_Serv i ces . - 
IO_User_Commun i cat i on_Serv i ces . - 
Cha i n_Process i ng . - 
Chai n_Interf ace 
Build: 3 

Requirements Reference: PQC System I/O S ervices Functional Require 

ments . Section 3.1 .4.2 


Inputs: 

• Activate_Chai n from Queue Processing (4. 1.2.1) 

• Root_Link_Command from Queue Processing (4.1 .2.1) 


Outputs: 

• Chain_Initiation_Command to I/O Interface (4.1.3) 

Notes: The implementation of this process must not be inter- 

rupted. The process monitors all inputs to detect 
when they change. This process may control other pro- 
cesses via interrupt signals 

Description: 


This process controls the access of Queue Processing (4.1 .2.1) to I/O 
Interface (4.1.3). 


It causes I/O Interface (4.1.3) to perform a chain of transactions by 
passing the Chai n_Identif ier, indicated by a new .value in 
Activate_Chai n, and the Root_Link_Identif iers, indicated by the last 
value received for Root_Li nk_Command, as Chai n_Ini t i at ion_Command. 
The Root_Link_Identif iers indicate the active root 1 i nk (s) for this 
I/O network. 
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Root_Li nk_ 
Command has 
new value 

\ 

/ 
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> > 

Ini tiation_ 

Cha incident if ier / 

Data 


Figure 3-8. Chain Interface (4.1 .2.3) 
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Process Name: 
Reference Number: 
Identifier: 


Bui id: 


I/O Interface 
4.1 .3 

IO_System_Servi ces .- 
IO_User_Commun i cat i on_Serv i ces . - 
I0_Interf ace 
3 


Requirements Reference: PQC System I/O Services Functional Require- 

ments . section 7 


Inputs: 

• IO_Data_Base.IO_Request_Def i ni t ion.I0_Chai n_Def i ni t ion 

• Chain_Ini tiation_Command from Chain Processing (4.1.2) 

• Current_Network_Parti tion_Def ini tion from Chain Proc- 
essing (4.1.2) 

• Output_Packet from Chain Processing (4.1.2) 

• Transact ion_Configuration_Data_Base from Chain Process- 
ing (4.1 .2) 

• Response_Frame from DIU and Node (4.1 .5) 

Outputs: 

• End_Of_Chai n^Status to Chain Processing (4.1.2) 

• Input_Packet to Chain Processing (4.1.2) 

• Command_Frame to Dill and Node (4.1.5) 


Notes: 


An instance of this process must exist for each I/O 
network connected to a GPC. 


Description: 


This process implements the performance of a chain of transactions to 
one or more DIUs or Nodes (4.1.5). The Chai n_Identi f ier of the chain 
to be performed is specified by Chai n_Ini tiation_Command. This input 
also specifies the root link processes that are to perform the chain. 
Data to be sent to each individual Node (4.1.5) or DIU is specified 
by an Output_Packet and communicated via Command_Frame. Data to be 
received from each Node (4.1.5) or DIU is received as a 
Response_Frame and stored as an Input_Packet. The completion status 
of a chain of transactions is specified in End_Of_Chain_Status. 
Other inputs are used by the various subprocesses to implement the 
above service. 


The subprocesses include: 

(1) Interface Initial Processing 

(2) Interface Completion Processing 

(3) Contention Processing 
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(4) Frame Transmitter 

(5) Frame Receiver 

Interface Initial Processing (4. 1.3.1) sets up the other subprocesses 
and initiates the performance of a chain of transactions. 

Interface Completion Processing (4.1 .3.2) collects data and status 
from the performance of each transaction and the chain as a whole to 
produce the outputs End_Of_Chai n_Status and Input_Packet. 

Contention Processing (4. 1.3. 3) gains access to the I/O network for 
this process. 

Frame Transmitter (4. 1.3. 4) transmits each Command_Frame. 

Frame Receiver (4.1 .3.5) receives each Response_Frame. 

The last four subprocesses exist as a unit for each connection of a 

GPC to an I/O network and are known as root link processes. Each set 

is identified by a Root_Link_Identif ier . These processes are per- 
formed in sequence as set up by Interface Initial Processing 
(4.1 .3.1) . 

For the general case of chain performance, Contention Processing 

(4.1 .3.3) (if used) is usually first. If completed successfully, it 

is followed by Frame Transmitter (4. 1.3. 4) and Frame Receiver 

(4.1 .3.5) (if needed) for each transaction. Interface Completion 
Processing (4. 1.3. 2) is invoked in parallel with each Frame Receiver 

(4.1 .3.4) invocation and may be invoked after the other subprocesses 

as well. It should be invoked at least once to produce 

End_Of_Chain_Status td indicate the outcome of Contention Processing 
(4.1 .3.3) . 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Interface Initial Processing 
4.1 .3.1 

I0_Sy s tem_Serv i ces . - 
IO_User_Commun i ca t i on_Serv i ces . - 
IO_Interface.- 

Interface Ini ti al_Process i ng 
3 


Requirements Reference: PQC System I/O Services Functional Require 

mania, section 7 


Inputs: 


• Current_Network_Part i tion_Def ini tion 

• IO_Data_Base.IO_Request_Def i ni t ion.I0_Chai n_Def i ni t ion 

• Output_Packet 

• Transact i on_Conf i gurat i on_Data_Base 

• Chai n_Ini t iat ion_Command from Chain Processing (4.1.2) 


Outputs: 

• End_Of_Chain_Status_Identi f ier to Interface Completion 
Processing (4. 1.3. 2) 

• Command_Frame_Status to Interface Completion Processing 
(4.1 .3.2) 

• Content ion_Data to Contention Processing (4. 1.3. 3) 

• HDLC_Program to Frame Transmitter (4.1 .3.4) 

• Output_Packet_Identi f i er to Frame Transmi tter (4.1 .3.4) 

• Receiver_State to Frame Receiver (4. 1.3. 5) 


Notes: None. 


Description: 

This process sets up the other I/O Interface (4.1.3) subprocesses to 
perform a chain of transactions to Nodes (4.1.5) or DIUs and initi- 
ates the performance of the chain. 

The above is accomplished via the following subprocesses: 

(1) Interface Chain Setup 

(2) Interface Transaction Setup 

Interface Chain Setup (4.1 .3.1.1) sets up the root link processes for 
the chain of transactions in general. It also decides whether or not 
to set up the performance for each transaction in the chain. 

Interface Transaction Setup (4.1 .3.1 .2) sets up the root link proc- 
esses Frame Transmitter (4.1 .3.4) , Frame Receiver (4.1 .3.5), and 
Interface Completion Processing (4.1 .3.2) for each individual trans- 
action, as directed by Interface Chain Setup (4. 1.3. 1.1). 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Interface Chain Setup 
4.1 .3.1 .1 

IO_System_Services .- 
IO_User_Commun i cat i on_Serv i ces . - 
IO_Interface.- 

Interface_Initial_Processing.- 
Inter f ace_Cha i n_Setup 
3 


Requirements Reference: POC System I/O Services Functional Require 

ments . section 7 


Inputs: 

• Current_Network_Part i tion_Def i ni t ion 

• IO_Data_Base.IO_Request_Def in? tion.IO_Chain_Def ini tion 

• Output_Packet 

• Transact i on_Conf i gurat i on_Data_Base 

• Chai n_Ini tiat ion_Command from Chain Processing (4.1.2)’ 

Outputs : 

• Interface_Transaction_Data to Interface Transaction 
Setup (4.1 .3.1 .2) 

• End_Of_Chai n_Status_Ident-i f ier to Interface Completion 
, Processing (4.1 .3.2) 

• Content i on_Data to Contention Processing (4.1 .3.3) 

• HDLC^Program to Frame Transmitter (4.1 .3.4) 

• Receiver_State to Frame Receiver (4. 1.3. 5) 


Notes: None 


Description: 


This process sets up the root link processes to perform the chain of 
transactions, decides whether or not to set up each transaction in 
the chain, and directs Interface Transaction Setup (4. 1.3. 1.2) appro- 
priately. It then initiates the performance of the chain. 


Content ion_Data communicates the Content ion_Pri or i ty to be used by 
Contention Processing (4.1 .3.3) and the Content ion_L imi t, the number 
of times the contention should be attempted before it is considered 
failed. 


HOLC_Program sets up Frame Transmitter (4.1 .3.4) to communicate 
Comma nd_Frames for Nodes (4.1.5) or Comma nd_Frames for DIUs. 

Receiver_State sets up Frame Receiver (4. 1.3. 5) to start or stop 
accepting Response_Frames . It is set up to start receiving frames 
before the first transaction is performed and to stop receiving 
frames after the last transaction has been completed. 
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Interface_Transaction_Data provides the data to Interface Transaction 
Setup (4. 1.3. 1.2) for each individual transaction. It communicates 
the identity of the Output_Packet used to initiate the transaction, 
the identity of the Input_Packet if a response frame is expected, the 
identity of the root link(s) to be set up, and either a Timeout_Value 
for determining when a transaction has failed due to the failure of a 
Response_Frame or a Time_Pad for determining how long to delay proc- 
essing within a root link. These data items are indicated for each 
transaction by the IO_Chain_Def ini tion specified by 
Chai n_Ini t i ation_Command. The IO_Chai n_Def i ni t ion also identifies 
each transaction within the chain. 

The decision concerning each transaction is determined as follows: 

• Processing for a particular transaction in the appropriate root 
link processes should be rearranged only if the conditions dic- 
tating the arrangement have changed since the last time they were 
examined. This rearrangement is performed by Interface Trans- 
action Setup (4. 1.3. 1.2). 

• Processing for this transaction in the appropriate root link pro- 
cesses is arranged so that this transaction will be performed 
when the chain is performed if and only if: 


- The 

value 

of 

Bypass 

i s "No" as 

indicated 

by 

the 

Transaction. 

.Configuration. 

_Data_Base, 




- The 

value 

of 

Select 

is "Yes" as 

i ndicated 

by 

the 


Transact ion_Conf iguration_Data_Base, and 
- The Network_Address specified by the Output_Packet for the 
transaction is reachable from the root link. This is indi- 
cated by indexing the Current_Network_Part i tion_Def i ni t ion 
with the Network.Address . 

Otherwise, processing for this transaction in the appropriate 
root link processes is arranged so that this transaction will not 
be performed when the chain is performed. 

• The processing for this transaction in the appropriate root link 
processes is replaced by a delay if and only if: 


The network is partitioned into more than one partition. 


- The 

value 

of 

Bypass is 

"Yes" as 

i ndicated 

by 

the 

Transaction. 

.Conf i 

iguration_Oata 

_Base, 




- The 

value 

of 

Select is 

"Yes" as 

i ndicated 

by 

the 


Transact ion_Conf i guration_Data_Base, and 
- The Network_Address specified by the Output_Packet for the 
transaction is reachable from the root link. This is indi- 
cated by indexing the Current_Network_Parti t ion_Def i ni t ion 
with the Network_Address. 

If the transaction is to be performed, the pertinent transaction 
data, i.e., Output_Packet_Ident i f i er , and, if needed, 
Input_Packet_Identif ier and Timeout_Value, are included in 
In ter face_Tr ansae t ion_Data. 
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If a transaction is to be replaced by a delay, only the Time_Pad 
value is included in Interface_Transaction_Data. 

If a transaction is not to be performed, no data need be transferred 
via Interface_Transaction_Data. 

After setup has been completed, the performance of the chain is ini- 
tiated only in the root link processes indicated by 
Chain_Ini tiation_Command (i.e., only the root links which are active 
for this particular I/O network). 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Interface Transaction Setup 
4.1 .3.1 .2 

I0_Sys tem_Serv i ces . - 
IO_User_Commun i ca t i on_Serv i ces . - 
IO_Interface.- 

Interf ace_Ini tial_Processing.- 
Interface Transaction_Setup 
3 


Requirements Reference: PQC System I/O Se rvices Functional Reouire- 

mftnti, section 7 


Inputs: 

• 

Interface_Transaction_Data from Interface 
(4.1 .3.1 . 7 ) 

Chain Setup 

Outputs: 





• 

• 

Output_Packet_Identi f ier to Frame Transmitter (4.1 .3.4) 
Command_Frame_Status to Interface Completion Processing 
(4.1 .3.2) 

Notes: 


None 


Descr.ipti 

on: 



As directed by Interface Chain Setup (4. 1.3. 1.1), this process 
arranges the processing for individual transactions in the appropri- 
ate root link processes (i.e., Frame Transmitter (4.1 .3.4), Frame 
Receiver (4.1 .3.5) , and Interface Completion Processing (4. 1.3. 2)). 
There are three processing options for a transaction: 


• Perform the transaction when the chain is performed, 

• Perform a delay (Time_Pad) instead of performing the transaction 
when the chain is performed, and 

• Skip the transaction when the chain is performed. 

One option is chosen for a transaction based on the input from 
Interf ace_Transact ion_Data. 

If Interface_Transaction_Data includes an Output_Packet_Ident i f ier , 
the processing for this transaction, in the root link processes spec- 
ified by the Root_L i nk_Ident i f i er (s) in the input, is set up so that 
the transaction will be performed when the chain is performed. Spe- 
cifically, the Output_Packet_Identi f i er is set up for the appropriate 
Frame_Transmi tters (4.1 .3.4) . 

If the input includes a Timeout_Value and an Input_Packet_Identi f ier , 
these items are set up, via Command_Frame_Status, for the appropriate 
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Interface Completion Processing (4.1 .3.2) processes specified by the 
Root_link_Identif ier (s) in the input. 

If the input, includes a Time_Pad value, the processing for this tran- 
saction, in the root link processes specified by the 
Root_L i nk_Ident i f ier (s) in the input, is set up so that a delay will 
occur instead of the transaction when the chain is performed. 

If the input does not include values for Output_Packet_Ident i f i er or 
Time_Pad, the processing for this transaction, in the root link proc- 
esses specified by the Root_li nk_Identi f ier (s) in the input, is set 
up so that the transaction is skipped when the chain is performed. 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Interface Completion Processing 
4.1 .3.2 

I0_Sys tem_Serv i ces . - 
IO_User_Commun i cat i on_Serv i ces . - 
I0_Interf ace.- 

Interf ace_Compi et i on_Process i ng 
3 


Requirements Reference: PQC System I/O S ervices Functional Require 

mcnts. section 7 


Inputs: 

• Command_Frame_$tatus from Interface Initial Processing 
(4.1 .3.1) 

• End_Of_Chain_Status_Identif ier from Interface Initial 
Processing (4.1 .3.1) 

• Content ion_Status from Contention Processing (4.1 .3.3) 

• Response_Frame_Data_And_$tatus from Frame Receiver 
(4.1 .3.5) 


Outputs: 


Notes: 


• End_Of_Chai n_Status 

• Input_Packet 

This process. Frame Transmitter (4.1 .3.4), Frame 
Receiver (4.1 .3.5), and Contention Processing 
(4.1 .3.3) form the root link processes. There is one 
set of these processes for each connection between an 
I/O network and a GPC. 


Description: 


This process produces the End_Of_Chain_Status and Input_Packets for 
the chain performed via this root link. It consists of the subproc- 
esses: 


(1) Interface Chain Completion 

(2) Interface Response Frame Processing 

Interface Chain Completion (4.1 .3.2.1) produces the 
End_Of_Chain_Status for the chain performed via this root link. 

Interface .Response Frame Processing (4.1 .3.2.2) produces 
Input_Packet (s) , if appropriate, for the transactions performed via 
th i s root link. 
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Process Name: 
Reference Number: 
Identi f i er : 


Build: 


Interface Chain Completion 
4.1 .3.2.1 

I0_Sy s tem_Serv i ces . - 
IO_User_Commun i cat i on_Serv i ces . - 
IO_Interface.- 

Inter f ace_Comp 1 et i on_Process i ng . - 
Inter face_Cha i n_Compl et i on 
3 


Requirements Reference: 



merits , section 7 


Inputs: 

• End_Of_Chai n_Status_Identi f i er from Interface Initial 
Processing (4.1 .3.1) 

• Content ion_Status from Contention Processing (4.1 .3.-3-) 

• Interface_Transaction_Status from Interface Response 
Frame Processing (4. 1.3. 2. 2) 

Outputs: 

• End_Of_Chain_Status to Chain Processing (4.1.2) 

Notes: This process. Frame Transmitter (4. 1.3. 4), -Frame 

Receiver (4.1 .3.5), Contention Processing (4.1 .3.3) , 
and Interface Response Frame Processing (4.1 .3.2.2) 
form the root link processes. There is one set of 
these processes for each connection between an I/O 
network and a GPC. 

Description: 

This process computes the End_Of_Cha i n_Status based on 
Content ion_Status and the Interface_Transaction_Status for each tran- 
saction that was performed in the chain. 

The Interface_Transaction_Status for the performed 
used to compute the End_Of_Chai n_Status 
A 1 l_Transactions_Fai led_Indicator 
At_least_One_Transaction_Fai 1 ed_Indi cator . 

Chai n_Not_Processed_Indicator in End_Of_Chai n_Status is used to indi- 
cate whether or not any transactions in the chain were attempted. 
This is based on whether or not Contention Processing (4.1 .3.3) suc- 
ceeded, as indicated by Content ion_Status. If this indicates that 
contention failed, it is assumed that no transactions were performed. 

The Bus_Error indicator in Contenti on_Status is also used to set the 
^ Bus_Error indicator in End_Of_Chain_Status. 


transactions are 
values for 
and 
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When all processing is completed, the Chain_Complete 
End_Of_Chain_Status is set to indicate that the chain of 
has been completed. 


indicator in 
transactions 
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Process Name: 
Reference Number: 
Identifier: 


Bui Id: 


Interface Response Frame Processing 
4. 1.3. 2. 2 

IO_System_Services .- 
IO_User_Commun i cat i on_Serv i ces . - 
IO_Interface.- 

Interf ace_Completion__Processi ng.- 
Interf ace_Response_F rame^Process i ng 
3 


Requirements Reference: PQC System I/O Services Functional Require 

ments . section 7 


Inputs: 

• Response_Frame_Data_And_Status from Frame Receiver 
(4.1 .3.5) 

• Command_Frame_Status from Interface Command Frame Proc- 
essing (4. 1.3. 2.1) 

Outputs: 


Notes: 


• Input_Packet 

• Interf ace_Transaction_Status to Interface Initial Proc- 
essing (4.1 .3.1) 

This process. Frame Transmitter (4.1 .3.4), Frame 
Receiver (4. 1.3. 5), Contention Processing (4. 1.3. 3), 
and Interface Chain Completion (4. 1.3. 2.1) form the 
root link processes. There is one set of these proc- 
esses for each connection between an I/O network and a 
GPC. 


Description: 

This process creates Input_Packets for transactions expecting 
responses and controls the timing between frame transmissions through 
the use of delays. 


If Command_Frame_Status includes a Timeout_Value and an 
Input_Packet_Ident i f i er , this process produces an Input_Packet. 

Otherwise, Command_Frame_Status includes only a Time_Pad value. In 
this case, processing is delayed for the length of time specified by 
Time_Pad and no outputs are produced. 


If an Input_Packet is to be produced, a timer is set. If the timer 
runs out before Response_Frame_Data_And_Status is received, 
Interface_Transact ion_Status is set to indicate "Failed" and the 
Input_Packet indicated by Input_Packet_Identif ier is updated to indi- 
cate a Response_Frame timeout. 
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Otherwise, Response_Frame_Data_And_Status is transformed into 
Input_Packet. If the status portion of this input indicates a legal 
frame, then Interface_Transaction_Status is set to indicate "Success- 
ful". 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Contention Processing 
4.1 .3.3 

IO_System_Services.- 
IO_User_Commun i cat i on . I0_Inter f ace . - 
Content i on_Process i ng 
3 


Requirements Reference: PQC System I/O Services Functional Require- 

ments . section 7 


Inputs: 


• 

Contention_Data from Interface Initial Processing 
(4.1 .3.1) 

Outputs : 


• 

Content ion_Status to Interface Completion Processing 
(4.1 .3.2) 

Notes: 

Instances of this process communicate via 

Content ion_Signa is transmitted across the I/O Network 

n • • 

This process. Frame Transmitter (4.1 .3.4) , Frame 
Receiver (4.1 .3.5), and Interface Completion Process- 
ing (4. 1.3. 2) form the root link processes. There is 
one set of these processes for each connection between 
an I/O network and a GPC. 


Description: 


This process contends for the I/O network to provide exclusive use of 
the network by the GPC. Contention is based on the 
Content i on_Pr i or i ty specified by Content i on_Data . 

If the process has not won the contention for the network after 
Content ion_Data. Max imum.Attempts, it returns a Content ion.Status 
value of "Failed". Otherwise, when it wins the contention, it 
returns a Contention_Status value of "Success". 

If the process detects the bus busy or stuck-on-high condition, this 
information is indicated in Content ion_Status. 
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Process Name: 
Reference Number: 
Went i f i er : 


Bui Id: 


Frame Transmitter 
4.1 .3.4 

IO_System_Services.- 
IO_User_Commun i cat i on_Serv i ces . 
lO^Interface.- 
Frame_Transmi tter 
3 


Requirements Reference: PQC System I/O Services Functional Require 

BfiOlSU section 7 


Inputs: 

• Output_Packet 

• HDLC_Program from Interface Initial Processing 
(4.1 .3.1) 

• Output^Packet^Identif ier from Interface Initial Proc- 
essing (4.1 .3.1) 

Outputs : 

i 

• Command_Frame to DIU and Node (4.1.5) 


Notes: This process. Frame Receiver (4. 1.3. 5), Contention 

Processing (4.1 .3.3) , and Interface Completion Proc- 
essing (4.1 .3.2) form the root link processes. There 
is one set of these processes for each connection 
between an I/O network and a GPC. 


Description: 


This process creates a command frame based on Output_Packet and 
HDLC_Program. 


HDLC_Program specifies how many residual bits should be appended to 
the end of Com mand_Frame data. This programmi ng remains in effect 
until the process is reprogrammed by Interface Initial Processing 
(4.1 .3.1) . 

Each Output.. Packet received is converted into a Command_Frame to be 
passed to a DIU or a Node (4.1 .5) process, based on 
Output_Packet. Address and the current HDLC programming. The trans- 
formation is a copy of the Output_Packet with the generation of 
Frame..Check_Sequence based on the bit string representing the 
Output_Packet. Constant value opening and closing flags are also 
added as part of the Command_Frame. 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Frame Receiver 
4.1 .3.5 

IO_Sy s tem_Serv i ces . - 
IO_User_Commun i cat i on_Serv i ces . 
IO_Interface.- 
Frame_Receiver 
3 


Requirements Reference: PQC System I/Q Services Functional Requi re- 

ments. section 7 


Inputs: _ 

• Receiver_State from Interface Initial Processing 
(4.1 .3.1) 

• Response_Frame from DIU and Node (4.1 .5) 


Outputs : 

• Response_Frame_Data_And_Status to Interface Completion 
Processing (4.1 .3.2) 

Notes: This process. Frame Transmitter (4. 1.3.4),. Contention 

Processing (4. 1.3. 3), and Interface Completion Proc- 
essing (4.1 .3.2) form the root link processes. There 
is one set of these processes for each connection 
between an I/O network and a GPC. 


Description: 


This process creates Response_Frame_Data_And_Status in response to 
receiving a Response_Frame. 

A Receiver_State value of "On" indicates the process should transform 
any Response_Frame that it receives to 
Response_Frame_Data_And_Status. A value of "Off" indicates that it 
should ignore any Response_Frame received. 

Response_Frame_Data_And_Status consists of a copy of 
Response_Frame. Address, .Control, .Data, and . Frame_Check_Sequence, 
and error indicators, byte count, and residual bits detected by the 
process. 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


GPC I/O Network Manager Support 
4.1 .4 

IO_Sy s tem_Ser v i ces . - 
IO_User_Commun i cat i on_Serv i ces . - 
GPC_IO_Network_Manager_Support 
Post 3 


Requirements Reference: Proof o f Concept System Functional — Requi re~ 

ments. i/o Network System Services. 

CSDL-AIPS-84-138 . Sect ion 5.0 


Inputs: 


Outputs: 


GPC_Subscr iber_IO_Error_Log 


GPC_Subscr iber_IO_Error_Report 
Notes: None. 

Description: 

This process provides a subset of the GPC's I/O error information to 
the manager of a particular network. 
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Process Name: 
Reference Number: 
Identifier: 


Bui id: 


Node 


4.1.5 

IO_Sys tem_Serv i ces . - 
IO_lJser_Commun i ca t i on_Serv i ces . - 
Node 


NA 


Requirements Reference: AIPS PQC System Design Specification. Net 

work Node 


Inputs: 

• Command_Frame from I/O Interface (4.1 .3) 

Outputs: 

• Response_Frame to I/O Interface (4.1 .3) 

Notes: 

• Nodes will be implemented with hardware and micropro- 
gram, not software 

• A node may take up to 512 microseconds to begin to 
reply, starting from the reception of the end of 
Comma nd.Frame 

• Sumcheck in Command_Frame is intended to protect 
against erroneous data transformations that might occur 
in portions of the GPC that are not redundant. The 
sumcheck mechanism must allow the recipient to detect 
any error caused by a single fault that occurred before 
CRC was appl ied. 

Description: 

A Node performs the following functions: 

• Detects activity and errors for each port 

• Enables and disables ports for network connectivity 

• Produces Response.Frames that contain information about detected 
activity and errors, and about the enable status of ports 

• Accepts arbitrary inputs to a Message Buffer for future inclusion 
in Response_Frames 

Activity and error detection are performed by the Node continuously. 

The detection of these conditions is latched in the Node's Status 

Register until the Status Register is cleared via a Command_Frame. 

The remaining functions are performed in response to Command_Frames . 
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On receipt of a Command_Frame addressed to the Node, the Node will 
check it for validity. If Comma nd_Frame is valid, the node will per- 
form one of the following sequences, as. specified by the content of 
Command_Frame. Otherwise the Node will ignore the Command_Frame 
except to indicate the error in the Node's Status Register. Note 
that the Node produces a Response_Frame for every valid Command_Frame 
addressed to it. 

• Replace the contents of the Node's Port Enable Register with the 
value included in Command.Frame and produce Response.Frame 

• Update the Node's Message Buffer and produce Response_Frame 

• Produce Response_Frame only 

Each Command.Frame also controls the following: 

• Whether the Response_Frame is to contain the Node's Status Regis- 
ter or Message Buffer 

• Whether the Response_Frame is to be deliberately transmitted with 
a protocol error 

• The number of residual bits to be included in Response_Frame 

• The port or ports on which the consequent Response.Frame is to be 
transmi tted 

e Whether the Node's Status Register is to be cleared after trans- 
mission - 

When Response_Frame contains the Node's Status Register, the activity 
and error status transmitted is that before these indicators are 
cleared (if requested), and the port configuration status transmitted 
is that after being updated by Command_Frame (if requested). 

The Command_Frame and Response_Frame formats are given in AIPS PQC 
System Design Specification. Network Node. 

A Command_Frame is honored by a Node if it meets the following crite- 
r ia. 

• Node.Address is the address of the node 
e Encoded_Node_Address is valid 

• Protocol checks (CRC, invalid frame, and abort) indicate legal 
protocol 

• The number of bytes received is valid 

• The number of bits after the last information byte, but before 
Frame_Check_Sequence, is valid (■ 3) 
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Sumcheck is valid 



3.2 I/O Network Manager Processes 


Process Name: 
Reference Number: 
Identifier: 

Build: 


IO_Network_Manager 

4.2. 

10 System_Services.IO Network Manager 
3 " 


Requirements Reference: PQC System I/O Services Functional Require 

ments . sections 4.0 and 5.0 


Inputs: 


• 

IO_Network_Manager_Command from System Manager (1 .) 


• 

Network_Def ini tion from I0_Data_Base 


• 

Manager_IO_Request_Data_And_Status from 1/0 User Commu- 
nication Services (4.1) 


• 

GPC_Subscr i ber_I0_Error_Report from 1/0 User Communi- 
cation Services (4.1) of all GPC Subscribers to Network 

Outputs: 


• 

I0_Network_Status_Report to System Manager (1 .) 


• 

Manager_IO_Request_Parameter to 1/0 User Communication 
Services (4.1) 


• 

Reconf iguration_Repor.t to I/O User Communication Ser- 
vices (4.1) of all GPC Subscribers to Network 

Notes: 


None. 

Description: 



Using the Network.Def i ni t ion, this process will grow a fault tolerant 
network to allow GPC subscribers on the network to communicate seri- 
ally with various I/O devices connected to the network. A network 
which provides I/O service to several GPCs is a regional network. 
Only one of these GPCs will run the 10 Network Manager process for 
the regional network. However, this process is also capable of man- 
aging a local I/O network, that is one dedicated to the exclusive use 
of one GPC. Since such a network may be partitioned into several sub- 
networks, this process will be able to manage a partitioned network. 

The network is grown or initialized by enabling various full duplex 
communication pathways through circuit switched nodes. Since not all 
possible pathways are enabled, the network has a set of spare links 
which allow it to be reconfigured in response to fault or damage 
events, rendering it resistant to such failures as a broken link, a 
transmitter or receiver stuck high or low, a babbling network ele- 
ment, or an element which responds to messages addressed to other 
elements . 
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The process periodically monitors the health of the I/O network by 
using the network to communicate with its nodes. This monitoring 
does not alter the configuration of a node. Rather a simple status 
read is requested of each node in the network. The node responds with 
its current configuration and an indication of whether or not it 
detected any errors since the last status read. I/O User Communi- 
cation Services returns this data and the errors it logged while 
conducting the node transaction to the network manager in 
Manager_IO_Request_Data_And_Status. The ability to conduct error 
free transmissions of this type is evidence of a properly functioning 
communication link. Errors of either type are evidence of the exist- 
ence of faults in the network. 

Another source of error information comes from the GPC subscribers to 
the network who send GPC_Subscr i ber_IO_Error_Reports to this process. 
This process uses the error information it collects while monitoring 
the network and that sent by its GPC subscribers to identify the net- 
work elements responsible for the errors. It then reconfigures the 
network using spare links so as to isolate the failed component and 
maintain an active communication link to all functioning elements in 
the network. 

Response to network failures is graduated in order to minimize the 
disruption of network activity by the repair process. Passive faults 
can be corrected most quickly while repair of a babbler may require 
regrowth of the network. 

Whenever a reconfiguration has been completed, this process writes a 
Reconf iguration_Report to all GPC subscribers on the network. This 
will enable them to reinstate bypassed transactions. In this way I/O 
User Communication Services can resume I/O activity with devices 
which were temporarily out of service due to network problems. 

This process communicates with nodes by sending them commands via I/O 
User Communication Services (4.1) which is sent a 
Manager_IO_Request_Parameter .IO_Servi ce_Request for that purpose. 
The data field of the command frame contains a Sumcheck which the 
node uses in its error detection logic. This Sumcheck will be com- 
puted by all subprocesses sending messages to nodes prior to issuing 
a Manager_IO_Request_Par ameter . I0_Servi ce_Request . 

When this process is configuring the network, either initially or in 
response to a failure, it will control the root link configuration of 
its host GPC. It will exercise this control by sending I/O User Com- 
munication Services a Manager_IO_Request_Parameter for that purpose. 
Another Manager_IO_Request_ Parameter will contain data regarding 
the current state of network partitioning which I/O User Communi- 
cations Services needs to conduct I/O on a partitioned network. 

This process will periodically report the status of the network 
nodes, either active or failed, to the global system manager so as to 
provide data for system FDIR. It will respond to 

IO_Network_Manager_Commands sent by the global system manager such as 
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a command to initialize the network as soon as the command is 
received. 

In order to insure that spare links can be confidently called into 
service to reconfigure the network after a failure, a routine test of 
these spare links will be conducted. This test will also attempt to 
exercise links (i .e. ports) which have a failed status in 
Network_Status. Thus a link marked failed due to a transient error 
can have its status upgraded to null. Following the test, the network 
is returned to its pretest configuration. Since this test performs a 
contingency function only, it can be scheduled at a rate which is low 
enough to minimally interfere with higher priority processes. 



Process Name: 
Reference Number: 
Identifier: 

Build: 


Control I/O Network 
4.2.1 

IO_Sys tem_Serv i ces . - 

IO_Network_Manager .Control_IO_Network 
3 ~ 


Requirements Reference: POC System I/O Services Functional Requi re- 

ments . section 4.0 


Inputs: 

• Network_Def i ni tion from IO_Data_Base 

• Manager_IO_Request_Data_And_Status from I/O User Commu- 
nication Services (4.1) 

• IO_Network_Manager_Command from System Manager (1 .) 

• Network_Faul t Indicator from Monitor I/O Network 
(4.2.2) 

• Network_Status 

• Current_Network_Def i ni t ion 

Outputs: 

• Manager_IO_Request_Parameter to I/O User Communication 
Services (4.1) 

• Network_Ini tial ization_Status to Network_Status 

• Reconf i guration_Status to Network_Status 

• Node_Status to Network_Status 

• Current_Network_Def ini tion 


Notes: None 


Description: 


Using the Network Definition, this process will initialize or grow a 
network in response to an In i t i a 1 i ze_Network_ Command from the System 
Manager (1.). The growth of a network may also begin upon a system 
reset if the network is local. This process will control its host 
processor's root link configuration during this growth phase by send- 
ing a Manager_IO_Request_Parameter .Root_Link_’Control_Request to I/O 
User Communication Services indicating the root link to be activated 
on the next transaction to a node of this network. Nodes will be 
sent commands to place their ports in a certain configuration by 
means of a Manager_IO_Request_Parameter .IO_Service_Request. Receipt 
of the configuration command will also cause the node to send back 
its current status by means of Manager_10_ Request_Data_And_Status . 
The success or failure of the initialization process will be written 
to Network_Status as the Network_Ini tial ization_Status. 


After initializing the network, the Control I/O Network process is 
only required to resume activity in response to a network failure as 
indicated by the Network_Faul t_Indicator from the Monitor I/O Network 
process (4.2.2). Using the Manager_IO_Request_Data_And_$tatus from 
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the chain on which the monitor detected errors, it must identify the 
location of the fault and reconfigure the network around the fault. 
During this attempt to reconfigure the network, it may be necessary 
to collect further information on the functioning of a particular 
communication link by additional reads of node status. This is done 
by sending the necessary Manager_IO_Request_Parameter to I/O User 
Communication Services. As with the initialization phase of this 
process, Control I/O Network will control the root link configuration 
of its processor to the network it is controlling. If the reconfig- 
uration process is performed, this information will be written to 
Network_Status as Reconf iguration_Status. If any nodes are discov- 
ered to be failed and hence isolated from the active network, the 
failed status of these nodes is written to Network_Status in 
Node_Status. Since Network_Status is used by Report I/O Network Sta- 
tus (4.2.3) on a periodic basis, it will be necessary for Control I/O 
Network to lock Network_Status at the time it begins execution and 
to unlock it when the process is completed. 

Finally, this process must respond to an indication that a partition 
has failed by repartitioning the network. The new partitioning of 
the network will be reported to I/O User Communication Services in a 
Manager_IO_Request_Parameter .Part i t ion_Update_Request conta i n i ng 
Current_Parti tion_Data. 


3-64 



Process Name: 
Reference Number: 
Identifier: 


Bui Id: 


Control Network Definition 
4.2.1 .1 

IO_System_Serv i ces . - 

IO_Network_Manager .Control_IO_Network . - 
Control_Network_Def i ni tion 
3 


Requirements Reference: PQC System I/O Services Functional Require- 

ments . section 4. 2. 1.2 


Inputs: 

• Network_Def ini tion from IO_Data_Base 

• IO_Network_Manager_Command from System Manager (1 .) 

• Parti tion_Status from Network_Status 


Outputs: 


Notes: 


• Manager_IO_Request_Parameter to I/O User Communication 
Servi ces (4.1 ) of host GPC 

• Cur rent_Networ k_Def i ni tion 

• Node_Status to Network_Status 

None 


Description: 


This process will update the Current_Network_Def ini tion whenever nec- 
essary with a new definition read from the IO_Data_Base. After the 
Initialize I/O Network (4.2.1 .2) process or the Maintain I/O Network 
(4.2.1 .3) process has responded to this new definition. Control Net- 
work Definition will send to I/O User Communication Services of its 
host GPC a Manager_IO_Request_Parameter .Parti tion_Update_Request 
which reflects the current partitioning of the network in 
Cur rent_Par t i tion_Data. 

There are three events which cause this process to update 
Current_Network_Def ini tion: 


(1) Receipt of an Ini t i al i ze_Network command from the System Manager 
indicating that Current_Network_Def i ni tion must be initialized so 
that a network may be grown. 

(2) Receipt of a Modi fy_Network_Def i ni tion command from the System 
Manager (1.). This command will be sent whenever a node is to be 
added to or removed from an existing network, thus changing the 
basic network definition. It will also be used to indicate that 
a failed node has been repaired and should be reconnected to the 
network. 
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(3) Parti tion_Status in Network_Status indicates a partition failure 
has occurred. 

There are two events which cause this process to send 
Current_Parti tion_Data to I/O User Communications Services of its 
host GPC: 


(1) Network_Ini t ial i zation_Status indicates that a network has been 
successfully grown. 

(2) Reconf iguration_Status indicates a change in a network configura- 
tion has been attempted. 

In both cases it is important that the Current_Parti tion_Data be sent 
to I/O User Communications Services before the 
Reconf iguration_Report. In the case where Reconf iguration_Report 
announces a network initialization has been completed, correct parti- 
tion information must be present for I/O activity to proceed. In the 
case where a reconfiguration report announces an attempt to repair a 
network, it causes transactions blocked by error indicators to be 
resumed. It is important that these reinstated transactions be sent 
through root links representing the current actual partitioning of 
the network. 

This process will block other processes from reading 
Current_Network_Oef i ni tion while it is obtaining a new value from 
IO_Data_Base to prevent use of a partially updated version. 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Handle Network Redefinition Events 
4.2. 1.1.1 

IO_System_Services.- 

I0_Networ k_Manager . Contro l_I0_Networ k . - 
Contro1_Network_Def i ni tion.- 
Hand 1 e_Networ k_Redef i n i t i on_Events 
3 


Requirements Reference: PQC System I/O Services Functional Require 

m&nls., section 4.2.1 .2 


Inputs: 

• Parti tion_Status from Network_Status 

• Network_Def ini tion from IO_Data_Base 

• IO_Network_Manager_Command from System Hanager (1 .) 

Outputs: 

• Send_Status to Network_Status 

• Node_Status to Network_Status 

• Cur rent_Networ k_Def i ni tion 


Notes: None 


Description: 


Upon reset (for a local network) or upon a Network_Ini t i a 1 i zat i on 
command (for a regional network) from the System Hanager (1.), this 
process will lock the Current_Network_Def ini tion. It will then ini- 
tialize Current_Network_Def ini tion from the IO_Data_Base. It will 
then send Network_Status a list of all nodes in the current network 
and mark their status null in Node_Status. It will indicate in 
Send_Status that Current_Part 1 t 1 on_Data has not been sent. Finally, 
it will unlock Current_Network_Def i n 1 t i on . 


Upon receiving a Modi fy_Network_Def i ni tion command from the System 
Manager, this process will lock the Current_Network_Def ini tion. It 
will then read a new definition from the IO_Data_Base and update 
Network_Status by adding a new node and marking its status null or by 
deleting a node as indicated by the command. It will indicate in 
Send_Status that Current_Parti tion_Data has not been sent. Finally, 
it will unlock Current_Network_Def ini tion. 


If Parti tion_Status indicates that a partition has failed, this proc- 
ess will obtain a new Current_Network_Def ini tion from the 
IO_Data_Base for the particular partition failure shown. It is pos- 
sible that no new definition will be issued. If a new definition is 
called for, it will first lock Current_Network_Def ini tion. Then it 
will indicate in Send_Status that Current_Parti tion_Data has not been 
sent. It will then read into Current_Network_Def ini tion the new net- 
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work definition data. Finally, it will 

Current_Network_Def i ni tion. 


unlock 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Send Current Partition Data 
4.2.1 .1 .2 

IO_System_Servi ces .- 

IO_Network_Manager .Control_IO_Network .- 
Control_Network_Def i ni t ion.- 
Send_Current_Parti tion_Data 
3 


Requirements Reference: PQC System I/Q Services Functional Require- 

ments . section 4.2.1 .2 


Inputs: 

• Reconf iguration_Status from Network_Status 

• Network_Ini tial ization_Status from Network_Status 

• Send_Status from Network_Status 

• Current_Network_Def i ni t ion 


Outputs: 

• Manager_IO_Request_Parameter to I/O User Communication 
Services (4.1 ) of host GPC 

• Send_Status to Network_Status 


Notes: 


None ■ 


Description: 


When Reconf iguration_Status or Network_Ini tial i zati on_Status indicate 
that a change in the network has occurred, this process will deter- 
mine the current partition state of the network from the 
Current_Network_Def ini tion and send this Current_Part i tion_Data to 
I/O User Communication Services of its host GPC as part of a 
Manager_IO_Request_Parameter .Parti tion_Update_Request. It will then 
mark Send_Status as sent. 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Initialize I/O Network 
4.2.1 .2 

I0_Sys tem_Serv i ces . - 
IO_Network_Manager . Contro1_I0_Network . 
Ini tial i ze_IO_Network 
3 


Requirements Reference: POC System I/O Services Functional Require 

ments . section 4. 2. 1.1 


Inputs: 

• Current_Network_Def ini tion from Control Network Defi- 
nition (4 . 2 . 1 . 1 ) 

• IO_Network_Manager_Command from System Manager (1 .) 

• Manager_IO_Request_Data_And_Status from I/O User Commu- 
nication Services (4.1) 

• Regrow_Network_Request from Maintain I/O Network 
(4.2.1 .3) 


Outputs: 


• Network_Conf iguration 

• Node_Status to Network_Status 

• Network_Ini ti al i zat ion_Status to Network_Status 

• Manager_IO_Request_Parameter to I/O User Communication 
Services (4.1) 


Notes: None 


Description: 


Using the Current_Network_Def i ni tion, this process is used to ini- 
tialize or regrow an I/O network. The algorithm used creates a max- 
imally branching, minimum path from a single processor to each node 
in the network. 


If the network is regional, the process will initialize that network 
upon receiving an Ini tial ize_Network command from the System Manager 
(1 .) . If the network is local, the initialization is started upon a 
reset of the local GPC. However, the System Manager (1.) may also 
command the initialization of a local network. Furthermore, to 
reconfigure the network under worst case failure conditions, the 
Maintain I/O Network process (4.2.1 .3) may find it necessary to 
regrow the entire network. It will issue a Regrow_Network_Request 
for this purpose. The Initialize Network process will be used to 
accomplish that reconfiguration. 

This process will be able to initialize or regrow a partitioned net- 
work. However, each partition will be grown as an atomic unit rather 
than in parallel with the other partitions in the network. Thus par- 
tition #1 would be completely grown before the growth of partition #2 


i 
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begins and so on. It must also be possible to regrow a single parti- 
tion so that a failure in one partition can be repaired without dis- 
rupting communications on unfailed partitions. 

While this process is running, it will coordinate control of its host 
GPC's root links to the network by sending the appropriate 
Manager_IO_Request_Parameter .Root_l i nk_Contro1_Request to I/O User 
Communication Services (4.1) . This will provide initial assurance of 
a properly functioning root link to the network being managed. Fur- 
thermore, during the growth of a network, it is important that errors 
detected by I/O User Communication Services do not trigger a root 
link switch by that process. The growth algorithm is equipped to deal 
with these errors as indicated in Manager_IO_Request_Data_And_Status . 

To add a new node to the active tree of the network, this process 
sends the node an appropriate Conf iguration_Comrfiand as a 
Manager_IO_Request_Parameter . IO_Service_Request. A properly func- 
tioning node will respond with its status which is returned to this 
process as Manager_IO_Request_Data_And_Status . If this transaction 
is completed without errors, it indicates that this node is now part 
of the active network. These transactions are conducted without con- 
tention for two reasons. In the first place, nonmanager GPC subscrib- 
ers are connected to the network by the manager only after its 
initial growth is complete. Hence, during that growth period, there 
is no one on the network with whom the manager need contend. Second- 
ly, during a network failure such as the presence of a babbling ele- 
ment on the network, contention mechanics may not be operable. 
Reinitialization of the network under failure conditions of this type 
is carried out to identify and isolate the babbler. 

As ' r each node is added to the network, the Network.Conf iguration is 
updated with the current configuration of each node on a port by port 
basis. Prior to beginning the initialization process, the status of 
each node in Node.Status is marked Null. Where an attempt to connect 
a node to the network is successful, the status of that node is 
changed to Active. If a node is found to respond to addresses other 
than its own, its status will be marked failed. Any nodes which 
still have a Null status after the network growth is completed will 
have their status changed to failed. Thus the failure of a single 
port of a node does not cause the entire node to be considered 
failed. Only after the growth process is complete will the identity 
of these unreachable nodes be apparent. 

This process will set Network_Ini tial ization_Status in Network_Status 
to its current state. During an initialization this state will be 
"Initialization In Progress: Final Status Pending". After an initial- 
ization attempt is completed three possible states could be recorded. 
These all begin with "Initialization Completed" followed by one of 
these modifiers: "Final Status Fully Successful" (when all nodes are 
active), "Final Status Partially Successful" (when at least one node 
is active), and "Final Status Failed" (when no nodes are active). 

This process must coordinate the efforts of several subprocesses 
involved in initializing a network. When Handle Network Redefinition 
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Events (4. 2. 1.1.1) unlocks the Current_Network_Def ini tion, this proc- 
ess will coordinate the growth of the network described therein with 
the fol lowing loop: 

For each partition in the network 
Repeat 

Select A Root Link (4.2.1 .2.1) 

Attempt to Grow to its Root Node (4. 2. 1.2. 2) 

Until (a data link is established with a root node) 
or (no more root nodes remain to be tried) 

If a data link is established with a root node 
then Complete Growth of the Partition (4.2.1 .2.3) 
else indicate in Network_Status that the 
partition is failed 
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Process Name: 
Reference Number: 
Identifier: 


Bui Id: 


Select Root Link 
4.2.1 .2.1 

IO_System_Services.- 

IO_Network_Manager .Control_IO_Network .- 
Ini t i al i 2e_I0_Network .Se1ect_Root_L i nk 
3 


Requirements Reference: POC System I/O Services Functional Require 

mfini&t section 4.0 


Inputs: 

• Current_Network_Def i ni t ion 

Outputs: 

• Current_Root_Link to Grow to Root Node (4. 2. 1.2. 2) 

• Manager_IO_Request_Parameter to I/O User Communication 
(4.1) 


Notes: None 


Description: 


This process is called as the first step in the growth of a network 
partition. It obtains the next root link of the current partition, 
that is the one being grown, from Current_Network_Def i ni tion. It 
sends to I/O User Communication Services (4.1) a 
Manager_IO_Request_Parameter .Root_L i nk_Control ..Request to obtain 
activation of the selected root link and to disable the root link 
switching capabilities of that process. Select Root Link then passes 
the address of the activated root link obtained from 
Current_Network_Def ini tion to Grow to Root Node (4.2.1 .2.2) in 
Current_Root_L i nk which will then begin its activity. 
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Process Name: 
Reference Number: 
Identifier: 


Bui Id: 


Grow to Root Node 
4.2.1 .2.2 

I0_Sys tem_Serv i ces . - 

I0_Networ k_Manager . Control_IO_Networ k . - 
Initialize 10 Network. Grow_To_Root_Node 
3 


Requirements Reference: PQC System I/O Services F unctional Require 

ments . section 4.0 


Inputs: 

• Current_Root_L i nk from Select Root Link (4. 2. 1.2.1) 

• Manager_IO_Request_Data_And_Status from I/O User Commu 
nication Services (4.1) 

• Current_Network_Def i ni tion 


Outputs: 


Notes: 


• Link_Status to Network_Status 

• Node_Status to Network_Status 

• Node_Conf iguration to Network_Conf iguration 

• Manager_IO_Request_Parameter to I/O User Communication 
Services (4.1) 

• Active_Root_Node to Complete Partition Growth 
(4.2.1 .2.3) 

None 


Description: 


This process looks up the Current_Root_Li nk in the 
Current_Network_Def ini tion to obtain the address of the node it must 
enable. It sets up the configuration command to be sent to this root 
node. The configuration command will tell the node which of its five 
ports to enable and which to disable. When growing to a root node 
only the port attached to the root link is enabled. The other four 
are disabled. The port number to be enabled is obtained from the 
Cur rent_Networ k_Def i ni tion. The process sends this configuration com- 
mand as part of a Manager_IO_Request_Parameter .I0_Servi ce_Request. 
The process also specifies that this transaction is performed without 
contention. 


When Manager_IO_Request_Data_and_Status is ready, the process will 
resume. It will first check the error indicators therein to determine 
whether or not the transaction was in fact sent and if any trans- 
mission errors were detected during the transmission. If the trans- 
action was conducted with no errors, the data will be checked to 
verify that the node has implemented the correct configuration. If 
no transmission errors were detected and the node configuration is 
correct, the Node_Status of this node is marked Active and the con- 
figuration of this node is recorded in Network_Conf i gurat i on. To 
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accomplish the latter means that the Node_Conf iguration of this node 
will show the enabled port marked Inboard and the other ports marked 
Null. The Link_Status of the root link is also marked active. Since a 
successful data link to a root node has been established, 
Active_Root_Node can be assigned its address. Processing control can 
now pass to the Complete Partition Growth process (4. 2. 1.2. 3) to 
which Active_Root_Node will be sent. 

If error indicators are present in Manager_IO_Request_Data_And_Status 
or if the port configuration data sent back from the node does not 
match the configuration that was sent to it, the configuration com- 
mand will be sent again. This is done to allow for the possibility 
that the error indicators were set by transient faults in the network 
and because failure to grow to a root node results in the failure of 
the entire partition when there is only one root link to the parti- 
tion. 

If the second try is successful, the data structures are updated and 
processing continues as described above. If the second try fails, 
then in Network_Conf igurat ion. Node_Conf iguration the status of the 
port which could not be enabled is marked failed and the Link.Status 
of this root link is marked failed. If another root link to that 
partition exists, processing control passes to Select A Root Link 
(4.2.1 .2.1). However, if no root links remain to be tried. 
Parti tion_Status of this partition in Network_Status is marked 
failed. Root links which have a failed status are not permanently 
failed, but instead will be routinely retried during spare link test- 
ing. If they operate properly at that time, their status will be 
upgraded to Null. 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Complete Partition Growth 
4.2.1 .2.3 

IO_System_Servi ces .- 

IO_Network_Manager . Control _I0_Network .- 

Ini tial ize_IO_Network.Complete_Parti tion_Growth 

3 


Requirements Reference: PQC System I/O Services Functional Require- 

ments . section 4. 2. 1.1 


Inputs: 

• Current_Network_Def ini tion 

• Manager_IO_Request_Data_And_Status from I/O User Commu- 
nication Services (4.1) 

• Active_Root_Node from Grow To Root Node (4. 2. 1.2. 2) 

Outputs: 

• Node_Conf iguration to Network_Conf iguration 

• Link_Status to Network_Status 

• Parti tion_Status to Network_Status 

• Manager_IO_Request_Parameter to I/O User Communication 
Services (4.1) 


Notes: None. 


Description: 

This process becomes active once Grow To Root Node (4.2.1 .2.2) 
receives a consistent response from a root node of the current parti- 
„ tion and sends the Acti ve_Root_Node to this process. The root node 
address initializes a spawning node queue. The root node becomes the 
first spawning node. The growth algorithm then enters a loop which 
consults the tables in Current_Network_Def i ni t ion to obtain the iden- 
tities and addresses of the network elements adjacent to the node at 
the top of the spawning node queue. This topmost node is called the 
spawning node. As the ports of the spawning node are enabled, its 
adjacent network elements are brought into the active tree. Config- 
uration commands are sent to the nodes via 
Manager_IO_Request_Parameter .IO_Service_Requests sent to I/O User 
Communication Services (4.1). 


If the adjacent element is a GPC, the port of the spawning node fac- 
ing that element is placed on a GPC subscriber list. If the adjacent 
element is a DIU, the port of the spawning node is placed on a DIU 
subscriber list. These ports will be enabled after the network growth 
is complete. 

If the adjacent element is a node, an attempt is made to create a 
functional link to that node. If the attempt is successful, this node 
is placed at the end of the spawning queue. Creating a functional 
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link requires that a port of the spawning node and a port of the 
adjacent or target node be enabled; the spawning node is enabled 
first. Enabling each port is accomplished by sending a 
Manager_IO_Request_Parameter ,I0_Servi ce_Request with the correct con- 
figuration of the node to I/O User Communication Services (4.1) which 
in turn sends the configuration command to the node. I/O User Commu- 
nication Services returns the response of the node to this command in 
Manager_IO_Request_Data_And_Status. The absence of error indicators 
on both transactions (to the spawning node and to the target node) is 
evidence of a properly functioning link. As each port is processed, 
Link_Status in Network_Status and Node_Conf iguration in 
Network_Conf iguration are updated. The Link_Status of a link may be 
active or failed. The Conf iguration_Status of a port may be inboard, 
outboard, null or failed. 

If the adjacent element is a DIU, that port is enabled. If no errors 
are reported in Manager_IO_Request_Data_And_Status from this trans- 
action, the port remains enabled. However, if errors are reported, 
indicating a babbling DIU, the port is returned to an inactive state. 
The final status of the port is recorded in Conf iguration_Status. 

When all ports of the current spawning node have been processed, the 
spawning node is removed from the spawning queue and placed on the 
active node list. The next node in the queue becomes the current 
spawning node and the cycle repeats itself. When the spawning queue 
is empty, the partition growth of the node network is completed. In 
the case of a partitioned local network, the ports on the DIU sub- 
scriber list remain to be enabled. In the case of a regional net- 
work, the ports on both the DIU and GPC subscriber lists must be 
enabled. 

The ports on the DIU subscriber list are enabled first. The correct 
configuration command is sent to each node on this list one at a time 
via a Manager_IO_Request_Parameter.IO_Service_Request. If no errors 
are reported in Manager_IO_Request_Data_And_Status from this trans- 
action, the port remains enabled. If an error is reported, the port 
is returned to an inactive state. An error detected after enabling 
this port could be due to two causes: a failed network element (such 
as a a babbling DIU or a failure in the port adjacent to the DIU) or 
a DIU responding to a previously issued command from a GPC. The pur- 
pose of enabling the DIUs after the growth of the node network is 
completed is to allow enough time to elapse to ensure that a DIU 
would have completed any outstanding GPC commands. Thus any errors 
detected after enabling the port adjacent to a DIU are indications of 
a faulty network component. Node_Conf i guration and Link_Status are 
updated following each configuration attempt. 

The ports adjacent to GPC subscribers on the subscriber list are also 
enabled one at a time. However, only the first of these nodes may be 
sent a message without contention. Once the network manager gives 
other GPCs access to the network, the manager must use the contention 
rules which govern access to a multiuser network. The 
Manager_IO_Request_Data_And_Status which is returned to this process 
after enabling the root node port of a GPC is ignored. Since a GPC 
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which is facing a port which is not enabled will not detect any net- 
work activity, it may be attempting to use the network at the time 
the port is enabled. This could result in errors being detected in 
the node's reply to its configuration command. To verify that the 
GPC is in fact not babbling, however, the manager must ask for* a sta- 
tus read of that node with contention. If the transmission has 
errors, that port is returned to a null status. This-phase of network 
growth is complete when all the ports on the subscriber list have 
been enabled and verified for proper functioning. Node_Conf iguration 
and Link_$tatus are updated following each verification transaction. 

This growth algorithm generates the shortest path from the source 
processor to any node in the network. Furthermore, if a path exists 
to any node in a network, this algorithm ensures that it will be 
found and activated, even if the network is degraded by failures. 

Two network failure modes are addressed and corrected by this algo- 
rithm, thus making it a useful backup tool for network maintenance 
when less drastic measures fail to isolate and remove a problem. The 
two failure modes are a babbling network element and a network node 
.which talks out of turn, i.e. responds when another network node 
been addressed. The operation of the part of the algorithm which 
deals with these failures is described below. 

When the process enables a port of the spawning node adjacent to a 
babbler, the babbler will interfere with the status report the spawn- 
ing node sends following its reconfiguration. This will result in 
the reconfiguration of this port to a null state, thus isolating the 
babbler from the rest of the properly functioning network. The meth- 
od works because the network links are full duplex and the reconfig- 
uration command will reach the spawning node through the data line 
not corrupted by the babbler. If the spawning node itself is babbling 
from a spawning port, the target node will not respond to the cor- 
rupted message. Thus the target node wi 1 1 not be connected to the 
babbler . 

After a new node appears to be successfully connected to the network, 
each node in the network is commanded to report its status, whether 
or not it is in the active tree. If an unconnected node (i.e. one 
which is not on either the spawning queue or the active node list) 
responds to this command, the most recently connected node is talking 
out of turn to this address. This newly added node must be discon- 
nected from the active tree by setting the correct spawning node port 
to a null state. Furthermore, its status in Node.Status is marked 
failed, since the address decoding function of a node is a central 
function, independent of the port receiving the address. A previous- 
ly connected node could also respond with errors. This means that 
either this node has recently failed or the most recently added node 
is talking out of turn. This last added node is then removed from the 
network as described above. The node or nodes which had errors on 
the previous test are again queried for status. If the error indica- 
tors are gone, it confirms the talker out of turn hypothesis, and the 
status of the removed node is set to failed. If not, it indicates 
that a failure has occurred during the growth process. In the former 
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case, the growth process is continued. In the latter case, the growth 
process must begin again from Select Root Link (4. 2. 1.2.1). 

Once the network growth is completed, any nodes with a Null status 
are set to a failed status. 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Maintain I/O Network 
4.2.1 .3 

I0_Sys tem_Serv i ces . - 

IO_Network_Manager . Control_IO_Network . 
Maintai n_IO_Network 
3 


Requirements Reference: POC System I/O Services Functional Require 

ments . section 4.2.1 .4 


Inputs: 

• Manager_IO_Request_Data_And_Status from I/O User Commu- 
nication Services (4.1) 

• Network Fault Indicator from Monitor I/O Network 
(4.2.2) 

• Node_Conf iguration from Network_Conf iguration 

• Current_Network_Def i ni tion 

• Network_Status 


Outputs: 

• Manager_IO_Request_Parameter to I/O User Communication 
Services (4.1) 

• Node_Conf iguration to Network_Conf iguration 

• Regrow_Network_Request to Initialize I/O Network 
(4.2.1 .2) 

• Node.Status to Network.Status 

• Link.Status to Network_Status 

• Parti tion_Status to Network_Status 


Notes: 


For Build 3 the response to a detected network fault 
will be to regrow the network. 


Description: 


This process has two related but nevertheless distinct functions. 
Its primary purpose is to restore the network to a fully operational 
state whenever the failure of some network component disrupts the 
proper functioning of the network. This is an aperiodic process which 
only becomes active in response to the detection of a fault in the 
network. 


A second function of this process is to verify that the various error 
detection mechanisms in the nodes are operating properly. Further- 
more , this second function must determine whether or not spare ports 
which the first function requires for repairs are operating properly. 
This process is periodic in nature. However, since it performs only 
a contingency function, it can be scheduled to run at a rate which 
does not i nterf ere wi th the scheduling of higher priority processes. 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Repair Network Fault 
4.2.1 .3.1 

IO_System_Servi ces.- 

IO_Network_Manager . Contr o l_IO_Networ k . - 
Maintain_IO_Network.Repair_Network_Faul t 
3 


Requirements Reference: POC System I/O Services Functiona l Require 

ments . section 4.2.1 .4 


Inputs: 

• Manager_IO_Request_Data_And_S tatus from I/O User Commu- 
nication Services (4.1) 

• Network_Fault_Indicator from Monitor I/O Network 

(4.2.2) 

• Node_Conf iguration from Network_Conf iguration 

• Network_Ini tial i zation_S tatus from Network_$tatus 

• Current_Network_Def i ni tion 

Outputs: 

• Manager_IO_Request_Parameter to I/O User Communication 
Services (4.1) 

• Node_Conf iguration to Network_Conf iguration 

• Predecessor_Li st to Network_Conf iguration 

• Regrow_Network_Request to Initialize I/O Network 

(4.2.1 .2) 

• Node_Status to Network_S tatus 

• Link_S tatus to Network_S tatus 

• Parti tion_S tatus to Network_Status 


Notes : 


For Build 3 the response to a detected network fault 
will be to regrow the network. 


Description: 


Each time Network_Ini t i al i zation_Status indicates a new network has 
been grown, this process will compute a Predecessor_Li st for each 
node in the network whose status in Node_Status is marked Active. 
Predecessor_lists are used in the identification of the source of a 
network failure. The algorithm for computing the Predecessor_Li sts 
i s as fol lows: 


For each node in the network 
Include the Current Node on its own Predecessor_List 
Repeat 

Find the Inward Port of the Current Node 
in Node_Conf iguration 

Find the network element adjacent to this current node 

through this Inward Port from 

Current_Network_Def i ni t i on 
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If this element is a node 

then add this adjacent node to the Predecessor_List 
The adjacent node becomes the Current Node 
Until the adjacent network element is a GPC 

Following the initialization of the Predecessor_Li sts this process 
again becomes active upon receiving a Network_Fau1 t_Indi cator from 
Monitor I/O Network (4.2.2). The action taken by this process will 
depend upon the type of failure reported in the 
Network_Faul t_Ind i cator . 

If a node is transmitting valid data through a port which should be 
disabled, the node must be removed from the network. If this failed 
node is not removed, each time the manager asks for status from the 
node adjacent to this port, it would receive two valid commands to 
report its status. Only one response is expected. Once the first 
response is received, another node will be commanded to report its 
status. The second response of the node may interfere with the reply 
of the next node, making it appear that this next node has failed to 
respond correctly to a command. Once the failed node has been removed 
from the network, any nodes which had transmission errors reported 
against them should again be queried for status to determine whether 
or not the fault was due to the failure just corrected. Nodes now 
functioning properly can have their Network_Faul t_Indi cator cleared. 

To remove a node from a network requires that nodes adjacent to its 
Outboard ports have their Inboard ports configured to be Null. Once 
this is accomplished, the node adjacent to its .Inboard port shall 
have its corresponding Outboard port disabled as well. Next the 
Current_Network_Def i ni t ion and the Network_Conf iguration are con- 
sulted to determine through which spare port the new link to these 
nodes will be made. Finally new links from the nodes adjacent to the 
chosen spare ports are established. The communication with a node is 
conducted by sending the appropriate 

Manager_IO_Request_Parameter . I0_Serv i ce_Request . The ver i f i cat i on 

that the node has carried out the correct configuration command is 
contained in the Manager_IO_Request_Data_And_Status returned after 
each transaction with a node. 

If the Network_Fault_Indi cator shows that the contention mechanism 
has failed (e.g. a babbler keeps the network in an active condition 
for an excessive length of time preventing a contention from taking 
place, or a data line is stuck high making it impossible for any GPC 
to win a contention) the network will be regrown by sending to Ini- 
tialize I/O Network (4.2.1 .2) a Regrow_Network_Request. 

If the Network_Faul t_Indi cator shows that one node in a partition has 
failed, an attempt will be made to reconnect that node to the network 
through one of its spare ports. 

If the Network_Faul t_Ind i cator shows that a subset of nodes on a 
partition has failed, the Predecessor_Li sts of these nodes is com- 
pared to identify the site of the failure. The last entries in these 
lists should match until a failed node appears on each list. If they 
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do not match, it means that two or more faults have occurred. In 
this case, the partition will be regrown. If the entries do match 
however, the fault can be isolated by finding the first node from the 
end of the list which itself has been reported as having failed. An 
attempt to reconnect this node to the partition through one of its 
spare ports will be made. Following the success of this reconfigura- 
tion, the other failed nodes will be queried for status. If the 
reconfiguration does not bring all the failed nodes back into ser- 
vice, the partition is regrown. 

Following a reconfiguration of a partition, the Predecessor..!. i sts are 
recomputed. Also Parti tion_Status and Reconf igurat ion.Status in 
Network.Status are updated to reflect the current state of the net- 
work or partition. Furthermore, following the reconfiguration of an 
individual node, Node_Conf iguration in Network_Conf i gurat ion and 
Node.Status and Link_Status in Network_Status are also updated. 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Test Network Components 
4.2.1 .3.2 

I0_Sys tem_Serv i ces . - 

IO_Network_Manager .Control _I0_Network.- 
Maintain_IO_Network.Test_Network_Components 
post 3 


Requirements Reference: POC Syste m I/O Services Functional Require 

ments . section 4.2.1 .4 


Inputs: 

• Manager_IO_Request_Data_And_Status from I/O User Commu- 
nication Services (4.1) 

• Node_Conf iguration from Network_Conf iguration 

• Current_Network_Oef i ni t ion 

• Network_Status 


Outputs: 

• Manager_IO_Request_Parameter to I/O User Communication 
Services (4.1) 

• Node_Status to Network_Status 

• L i nk_Status to Network_Status 


Notes: None 


Description: 


The function of this process is to verify that the various error 
detection mechanisms in the nodes are operating properly. Further- 
more , this process must determine whether or not spare ports which 
are required for repairs are operating properly. This process is 
periodic in nature. However, since it performs only a contingency 
function, it can be scheduled to run at a rate which does not inter- 
fere with the scheduling of higher priority processes. 


All null and failed links will be routinely tested. Null links are 
tested to determine if they can be safely brought into service to 
reconfigure around a failure. Failed links are tested to determine 
whether or not the initial assignment of failed status was due to a 
transient fault unrelated to the link itself. To accomplish this it 
may be necessary to keep track of a link's performance over time. 
Links which repeatedly change status probably have an intermittent 
failure of some kind and should be dropped from the spare/failed 
testing cycle. To test a link requires the identification of the 
nodes on either end of the link. One of these nodes is designated the 
spawning node and the other is designated the target node. The tar- 
get node is first reconfigured so that ail its ports are disabled. 
The configuration of the spawning node is modified so that the port 
adjacent to the target node is enabled while its other ports retain 
their original pretest status. The target node is then reconfigured 
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to enable the port adjacent to the spawning node. If the status 
returned to this process by the target node is error free, the link 
is operating properly. In this case, Link_Status and Node_Status are 
updated to show a null status for the link and ports involved. If 
the link is not operating properly, its Link_$tatus and Node_Status 
are declared failed. In either case the target node and the spawning 
node are returned to their pretest configurations but this time the 
spawning node is reconfigured first. The order in which target and 
spawning nodes are reconfigured prevents the possible formation of 
loops in the network. 

Each of the error detection mechanisms in a node will be tested to 
determine that they are operating properly. Since the network manage- 
ment algorithms use this data to control the network, it is impor- 
tant that the data be valid. For example, a node can be commanded to 
transmit a frame from a given port which produces a CRC error in any 
port receiving the frame. Thus the ability to detect CRC errors in 
each port of a node can be verified by reading the status of the node 
being tested to clear its error indicators, commanding a node adja- 
cent to the one being tested to send out a frame with bad CRC and 
then reading the status of the node being tested. If it has detected 
the error, it has passed the test. 
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Process Name: 
Reference Number: 
Identifier: 

Build: 


Monitor I/O Network 
4.2.2 

IO_System_Services.- 

10 Network_Manager .Moni tor_I0_Network 
3 


Requirements Reference: PQC System I/O Services Functional Require 

ments . section 4.2.1 .3 


Inputs: 

• Manager^ IO_Request_Data_And_Status from I/O User Commu- 
nication Services (4.1) 

• Network_Ini tial ization_Status from Network_Status 

• Node_$tatus from Network_S tatus 

• Current_Network_Def ini tion from Control I/O Network 
(4.2.1) 

• GPC_Subscr iber_IO_Error_Report from I/O User Communi- 
cation Services (4.1) of all GPC Subscribers to the 
Network 


Outputs: 

• Manager_IO_Request_Parameter to I/O User Communication 
Services (4.1) 

• Network_Faul t_Indicator to Control I/O Network (4.2.1) 


Notes: 


For the POC system the frequency at which this process 
runs is variable. 


Description: 


Monitor I/O Network becomes active when Network_Ini tial i zation_Status 
indicates an active network has been grown. This process gathers 
information on the health of the network from two sources: the net- 
work nodes and the GPC subscribers to the network. It uses this 
information to determine if any faults have occurred in the network. 
If any faults are detected, this information is passed on to the Con- 
trol I/O Network process (4.2.1) in the Network_Faul t_Indicator . 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Collect Network Status 
4. 2. 2.1 

IO_System_Servi ces .- 

IO_Network_Manager .Moni tor_IO_Network . 
Col 1 ect_Network_Status 
3 


Requirements Reference: POC System I/O Services Functional Reoui.r_er 

mania, section 4.2.1 .3 


Inputs: 

• Manager_IO_Request_Data_And_Status from I/O User Commu- 
nication Services (4.1) 

• Network_Ini t i a 1 i zat i on_Status from Network_Status 

• Node_Status from Network_Status 

• Current Network_Def i ni t ion from Control I/O Network 
(4.2.1) 


Outputs: 

• Manager_IO_Request_Parameter to I/O User Communication 
Services (4.1) 

• Network Faul t_Ind i cator to Control I/O Network (4.2.1) 


Notes: 


For the POC system the frequency at which this process 
runs is variable. 


Description: 

This process becomes active when Network_Ini t ial i zation_Status indi- 
cates an active network has been grown. It will periodically command 
each node listed in the Current_Network_Def i ni t ion which 
Network_Status does not declare failed to report its status by send- 
ing to I/O User Communication Services (4.1.) a 
Hanager_IO_Request_Parameter .IO_Service_Request. These transactions 
are to be conducted on the network with contention. 


Collect Network Status is the fault detection mechanism of the net- 
work manager. This detection mechanism operates in two stages. 

When I/O User Communication Services transmits messages on the net- 
work to a node, it observes the success or failure of the communi- 
cation and records those observations in the status field of 
Manager_IO_Request_Data_And_Status. This constitutes the first stage 
of fault detection and includes detection of the failure of a node to 
transmit a response to a command in a reasonable amount of time, the 
presence of transmission errors on the network during a response from 
a node, and the incprrect number of words in a response. In addition 
to detecting errors on transactions to individual nodes, in this 
stage the overall performance of the network is monitored for fail- 
ures which impede the proper functioning of the contention sequence. 
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These failures include a babbler which is flooding the bus with mean- 
ingless signals and a data line which is holding the bus in a "stuck 
on one" condition. These errors are also reported to this process in 
the status field of Manager_IO_Request.J)ata_And_Status. 

The second stage of error detection involves the processing of the 
information returned in the data field of 
Manager_IO_Request_Data_And_Status. This represents the node's per- 
ception of its current state. This data is processed to verify that 
the port configuration reported by the node is correct, that no 
activity is detected on a port not currently enabled, and that no 
valid frames have been received on a port not currently enabled. The 
detection of activity on a port which is not enabled is an indi- 
cation that the node adjacent to that port is transmitting when it 
should be disabled. It is either babbling or transmitting valid 
data. The identification of which failure has occurred is made by 
observing whether or not the signals are valid (Val id_Frame_ Received 
is true). Furthermore, it may be possible to detect the existence of 
a recurring transient failure in the network by recording the node's 
detection of protocol errors on data flowing in the network for fur- 
ther analysis. 

If any errors are detected by this process, those errors will be 
described in the Network_Faul t_Indicator which is then sent to the 
Maintain I/O Network process (4.2.1 .3). 
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Process Name: 
Reference Number: 
Identifier: 

Build: 


Collect Subscriber Status 
4. 2. 2. 2 

IO_System_Servi ces .- 

IO_Network_Manager .Col lect_Subscr iber_Status 
post 3 


Requirements Reference: POC System I/O Services Functional Require 

merits , section 4.2.1 .3 


Inputs : 

• Network_Ini ti al i zation_Status from Network_Status 

• Node_Status from Network_Status 

• Current_Network_Def i ni t i on from Control I/O Network 
(4.2.1)“ 

• GPC_Subscr iber_IO_Error_Report from I/O User Communi- 
cation Services (4.1) of all GPC Subscribers to the 
Network 


Outputs : 


• Network_Fault_Indicator to Control I/O Network (4.2.1) 

Notes: For the POC system the frequency at which this process 

runs- i s variable. 

Description: 


This process will receive the GPC_Subscr iber_IO_Error_Report. Errors 
reported here when no errors have manifested themselves in the peri- 
odic node status reads are evidence of transient faults in the net- 
work or of faults which the manager's use of the network does not 
trigger. This information is passed on to the Maintain I/O Network 
process (4.2.1 .3) in the Network_Faul t_Ind i cator . 
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Process Name: 
Reference Number: 
Identifier: 

Build: 


Report I/O Network Status 
4.2.3 

IO_System_Serv i ces . - 

IO_Network_Manager .Report_IO_Network_Status 
3 (Partial Implementation - See Subprocesses) 


Requirements Reference: POC System I/O Services Functional Require 

ments. section 5.2.3 


Inputs: 

• Current_Network_Def i ni t ion 

• IO_Network_Manager_Command from System Manager (1 .) 

• Network_Ini t i al i zat i on_Status from Network_Status 

• Node_Status from Network_Status 

Outputs: 

• IO_Network_Status_Report to System Manager (1 .) 

• Reconf iguration_Report to I/O User Communication Ser- 
vices (4.1) of all GPC Subscribers to Network 


Notes: None 


Description: 


If Network_Status.ini ti al i zat ion_Status indicates an initialization 
of the network or if Networ k_Status. Reconf iguration_Status indicates 
a reconfiguration of the network, send a Reconf iguration_Report to 
I/O User Communication Services (4.1) of all GPC Subscribers to net- 
work. 


The IO_Network_Manager_Command is Send_Network_Status which will con- 
tain a parameter, Report_Rate, which will indicate whether the 
IO_Network_Status_Report is to be sent only upon a command from the 
System Manager (1.) or whether it will be sent periodically at a 
certain frequency until stopped by another Send_Network_Status com- 
mand . 
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Process Name: 
Reference Number: 
Identifier: 


Bui Id: 


Report To GPC Subscribers 
4. 2. 3.1 

IO_System_Serv i ces . - 

IO_Network_Manager .Report_IO_Network_Status . 
Report_To_GPC_Subscr ibers 
3 


Requirements Reference: POC System I/O Services Functional Require- 

ments . section 5.1 .2.2 


Inputs: 


Outputs : 


Notes : 


Network_Identif ier from Current_Network_Def ini t i on 
Send_Status from Network_Status 

GPC_ Subscr i ber_Li st from Current_Network_Def i ni t ion 
Network_Ini tial ization_Status from Network_Status 
Reconf iguration_Status from Network_Status 


Reconf i gur at ion_Report to I/O User Communication Ser- 
vices (4.1) of all GPC Subscribers to Network 

None 


Description: 

This process will send a Reconf iguration_Report to the GPC Subscriber 
of a network whenever a reconfiguration of the network takes place 
and Send_Status indicates that Current_Parti tion_Data has been sent 
to I/O User Communications Services (4.1) of the host GPC. This 
includes the first time a network is configured or grown. 
Ini tial ization_Status in Network_Status records the initial growth of 
a network. Reconf i gurat i on_Status indicates that the network has been 
reconfigured to repair some failure or for some other reason such as 
a repartitioning of the network into subnetworks. These reports will 
contain the identifier of the network which has been reconfigured as 
indicated in Network_Identif ier . The destination of these reports is 
obtained from the GPC_Subscriber_List. 
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Process Name: 
Reference Number: 
Identifier: 


Build: 


Report To System Manager 
4. 2. 3. 2 

IO_System_Services.- 

IO_Network_Manager .Report_IO_Network_Status.- 

Report_To_System_Manager 

post 3 


Requirements Reference: POC System I/O Se rvices Functional Require 

ments . section 5. 2. 3. 2 


Inputs: 

• IO_Network_Manager_Command from System Manager (1 .) 

• Network_Identi f ier from Current_Network_Def i ni t ion 

• Node_Status from Network_Status 

• Network_Ini t i al i zation_Status from Network_Status 


Outputs: 

• IO_Network_Status_Report to System Manager (1 .) 
Notes: None. 


Description: 

The IO_Network_Manager_Command, Send_Network_Status, will contain a 
parameter, Report_Rate, which indicates whether 
IO_Network_Status_Reports should be sent upon receipt of 
Send_Network_Status only or instead should be sent periodically at 
some frequency specified in Report.Rate. 


The IO_Network_Status_Report generated by this process for the System 
Manager (1.) will contain information on the current state of the 
network as recorded in Network_Status . For example, if an attempt is 
made to initialize a network, this process will send a message to the 
System Manager (1.) based on the outcome of that attempt as logged in 
Network_Status.ini tial izat ion_Status by the Initialize I/O Network 
process (4.2.1 .2) . Network.Status may be locked by Control I/O Net- 
work (4.2.1). Thus Report to System Manager may have either to wait 
for Network.Status to be unlocked before sending its report or to 
send a report indicating that network status is pending. 

Until the Initialize I/O Network process has grown or failed to grow 
a network, the status of all nodes in the network is null. After that 
process has run, nodes will have either an active or failed status 
logged in Network_Status.Node_Status by that process. Updates to 
Node_Status will be made by the Maintain I/O Network process 
(4.2.1 .3) as necessary. Each IO_Network_$tatus_Report will indicate 
the current state of each node as logged in Node_Status. Finally, 
the IO_Network_Status_Report will include the address of the network 
which is the subject of the report as indicated in the 
Network_Ident i f i er . 
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SECTION 4 


DATA DICTIONARY 


4.1 Introduction 


This section contains a listing of every data item or data grouping 
identified on the data flow diagrams. Each entry includes a description 
of the data. 

Note: Descriptions are made in the context of how the data item 

is used in process descriptions from Chapter 3 and data 
flow diagrams from Chapter 2. 

The following conventions are used within data descriptions: 

• Data items that are a composite of other data items are described 
in one of three ways: 

— A vertical list of data items, each preceded by a bullet, 
that make up the composite or 

— A list of data items connected by plus signs, ?.g.. Data + 
Status, or 

— An English description of the data item. 

• Data items that are defined as a choice of one of a group of data 
items are described in one of three ways: 

— A vertical list, without bullets, of data items with a verti- 
cal bar symbol after each of the items excluding the last 
i tern, 

- A list of data items connected by vertical bars, e.g., Data I 
Data.Status I Status, or 

— An English description of the data item, e.g., "The item may 
be Data, Data.Status, or Status". 

• Data items may be described as a choice of values. Values are 
represented by text within double quotes. (The name of a value 
may serve as its own description.) 

• Data items that are defined as a collection of one or more data 
items (iterations of a data items) may be designated by placing 
the iterated data items in parenthesis, e.g., (Data_And_Status) 
to represent one or more elements made of Data_And_Status, and 


4-1 



(Data I Status) to represent a collection of one or more ele- 
ments, any of which may be either a Data or a Status item. 

• Where English description combined with the above syntactical 
symbols, it is either: 

- preceded by a double dash, " — ", or 

- separated from the rest of the definition by a blank line. 


4.2 Data 


Activate_Chain 

Chai n_Ident i f i er 

Act i ve_Root_Node 

Holds the address of the root node from which a network 
partition will be grown. Its value is used to initialize 
the spawning node queue. 

Address_M i smatch_Ind i cator 

"Mi smatch" 

I "Match" 

A1 1_Transactions_Fai led_Indi cator 

"A1 1 F a i led" 

I "Some.Succeeded" 

Appl ication_Initia1 ization_Request 

• Servi ce.Identi f i er 

• Function_Identi f ier 

At_Least_One_Transact i on_Fa i 1 ed_Ind i cator 

"A1 1 ..Succeeded" 

I "Some_Fai led" 


Bus_Error 

This data item is an indication that the signal on the net- 
work is stuck on high, that contention was aborted, or the 
network is busy such that contention cannot occur. 


Bypass 

"Yes" 

I "No" 

Bypass_Clear 
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"Clear" 

I "No-op" 

Bypass_C 1 ear_Queue_E 1 ement 
(Cha i n_Ident i f i er) 

Bypass_Enabled 

"Yes" 

I "No" 

Bypass_Ind i cator 

"Executed" 

I "Bypassed" 

Cha i n_Comp1ete 

"Chai n_Compl ete" 

I "Not_F I n i shed_Yet" 

Chai n_Comp1etion_Status 

"Next.Chain" 

I "Swi tch_Root_l i nk_And_Repeat_Cha i n" 

I "Swi tch_Root_Link_And_Next_Chain" 

This data item indicates whether I/O errors encountered 
while performing a chain imply that root link switching 
should be performed or that the chain should be retried. 
The possible values are: 

• Next_Chain indicates that root link switching should 
not be performed and the chain. should not be retried. 

• Swi tch_Root_Link_And_Repeat_Chain indicates that root 

link switching should be performed (if there is an 
alternative root link to switch to) and the chain 

should be retried after the switch. 

•• Swi tch_Root_Link_And_Next_Chain indicates that root 

link switching should be performed (if there is an 
alternative root link to switch to) but the chain 

should not be retried after the switch. 

Cha i n_Data_And_Status 

• Cha incident if ier 

• (Transact ion_Identi f ier + Data + Comfaul t_Indi cator + 
Bypass_Ind i cator) 

Chain_Identif ier 

— identifies a chain within an I/O network 
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Cha i n_In i t i at i on_Command 

• Chain_Identif ier 

• (Root_L i nk_Ident i f i er) 

Cha i n_In i 1 1 at i on_S tatus 

• Content ion_Status 

• Chai n_Identi f ier 

Cha i n_Not_Processed_Ind i cator 

"Processed" 

I "Not_Processed" 

Chain_Queue 

(Cha i n_Queue_E 1 ement) 

— This is a prioritized queue of Chain_Queue_Elements. 

Cha i n_Queue_E 1 ement 

Transact i on_Queue_E 1 ement 
I Root_Link_Queue_Element 
I Bypass_Clear_Queue_El ement 
I Selection_Queue_El ement 
I Network_Parti t i on_Queue_E 1 ement 

Chai n_S tatus 

This data item has content identical to 
End^0f_Chai n_S tatus . 

Chai n_T i meout_Va I ue 

This data item specifies how long an I/O chain is allowed 
to continue before being considered in error. The period 
being specified starts when the GPC performing the chain 
wins the contention. There is a unique value for every 
chain. This data item also indicates the Chain_identif ier 
for the chain. 

Cha in_Transaction_S tatus 

This data item is a summary of errors in all transactions 
of the chain being processed. The following values are 
possible: 

"No_Transact i on_Per formed" 

I "No_Errors_In_Chai n" 

I "At_Least_One_Error_In_Chai n" 

I "Errors_In_Al 1 ..Transactions" 

Comf au 1 t_I nd i ca to r 

"OK" 

I "Faulted" 
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This data item indicates to the process that requested the 
transaction whether or not the data received due to the 
transaction is suspect, i.e., that an error occurred during 
the transaction or that the transaction was not performed. 

Command.Frame 

This data item specifies the operation or operations to be 
performed by a node or DIU, and the output data, if any, 
appropriate to those operations. 

Figure C-2 on page C-4 shows the format of the packet por- 
tion (the portion between the Opening Flag and Closing 
Flag) of a Command_Frame. 

Command_Frame_Status 

Timeout_Value 5 Input_Packet_Identi f ier 
I Time_Pad 

Completion_Status 

Indicates the Cha i n_Ident i f i er for the completed chain and 
whether the determination of completion was based on its 
actually finishing, or on the detection of a timeout. The 
following values are possible. 

• Chain_0K means that the chain in progress finished 

before the chain timeout limit was reached. 

• Chain_Timeout indicates that the chain in progress was 

" - - - still in progress when the chain timeout limit was 

reached. 

• Unexpected_Cha incomplete means that an end of chain 

condition was detected at a time when no chain was in 
progress on the network in question. This indicates 
the detection of a "bus busy" condition. 

Content ion_0ata 

• Content ion_Pr i or i ty 

• Maximum_Attempts 

Content i on_Pr i or i ty 

— symbol representing the relative level of priority with 
which to contend for the bus 

Content ion_Status 

• "Content i on_Won" I "Content i on_Fa i 1 ed" 

• Bus_Error 

Current Network Definition 
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The version of Network_Def i ni t i on currently being imple- 
mented. 

Current_Network_Parti tion_Def ini tion 

(Partition_Identif ier + (DIU_Address I Node_Address) ) 

Current_Parti tion_Data 

Data reflecting the current partitioning of a network by 
the network manager in accordance with the 

Current_Network_Def ini tion. This data includes the number 
of partitions in a I/O network. It also includes the 

nodes, DIUs, and root links for each partition. 

Cur rent_Root_L i nk 

The identifier of the active root link to a partition which 
is about to be grown. 


Data 

— an array of one or more bits 
DIU_Address 

Network_Address — for a DIU 

Encoded_Address_Indi cator 

"Match" 

I "Mismatch" 

End_Of_Cha i n_Status 

• ' Cha incomplete 

• Chainl_Not_P r ocessed_Indi cator 

• A 1 l_T ra nsactions_F a ' 1 ed_Ind i cator 

• At_L®ast_One_Transaction_Fai led_Indi cator 

• More_Th ar >_Or>e_T ransact i on_P®r f ormed_Ir\d i cator 

• Bus_Error 

Indicates whether the chain in progress has completed, and 
if so whether I/O errors were detected during chain exe- 
cution. 

(1) Cha i n_C°mp 1 ete indicates whether the chain in progress 
has completed. 

(2) Error_St a t us indicates whether I/O errors prevented the 
GPC from winning a poll; whether there were I/O errors 
detected on all transactions in the chain, or on at 
least one transaction but not all; or whether response 
frames were expected from more than one DIU or node. 

End_Of _Ch® ■ n_Status_Ment i f i er 

This data item identifies an End_0f_Ch a ' n_Status data item. 

Er ror_Process_Inh i b i t 
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"Yes" 

I "No" 

F rame_Check_Sequence 

— data computed by the interface to detect bit errors 
within a frame 

Frame_Length 

— The combined length of the Network_Address, 
HDLC_Contro1_Byte, and Data fields produced by a 
Response_Frame for an Input_Packet 

F rame_Protocol_Er ror_Ind i cator 

"Yes" 

I "No" 

F unct i on_Ident i f i er 

This data item uniquely identifies an application function. 

GPC_Subscr i ber_Command 

(Funct i on_Ident i f i er) 

GPC_Subscr i ber_IO_Error_Log 

This is a file that stores the history of I/O errors 
detected by local GPCs. Each log entry includes the type 
and time of the error. 

GPC_Subscr i ber_IO_Error_Report 

This is information from a GPC subscriber to the I/O Net- 
... work Manager concerning the I/O errors the subscriber has 
experienced since the last such report. 

GPC_ Subscr i ber_L i st 

The complete list of identifiers of GPC subscribers to an 
I/O network. 

HDLC_Control_Byte 

— byte of information for HDLC control (not used) 
HDLC_Program 

"DIU_Communication" 

I "Node_Communication" 

Incor rect_Message_Length_Ind i cator 

"Yes" 

I "No" 

Inh i b i t_Sw i tch i ng_Ind i cator 

"Inhibi t_Swi tchi ng" 

I "A1 low_Swi tchi ng" 
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In i t i a 1 i ze_Networ k 

A command sent to the manager of a network by the System 
Manager (1.) requesting that a network be initialized or 
grown. It also contains an identifier of this network 
which selects the data describing this network in 
Network_Def ini tion. 

Input_Packet 

• Interf ace_Status 

• Frame_Length 

• Network-Address 

• HDLC_Control_Byte 

• Data 

• Frame_Check_Sequence 

Input—Packet_ Ident i f i er 

Packet-Identifier — for an Input-Packet 
Input-Packet— Length 

This data item specifies the length of an Input— Packet 
Inter face_ Cha 1 n_ T i meout— Va 1 ue 

This data item specifies the maximum period of time — 
after a contention has been won and before a chain has com- 
pleted — before the chain is declared failed. 

Inter fac.e-Status 

e Transaction_Timeout-Indicator 
•e Frame-Protocol-Error-Indicator 
e Residual-Bit-Count 

Inter face_T ransact i or\_Da ta 

e Timeout-Value 

• Output-Packet-Identifier 

• Input-Packet— Identifier 

Inter face_ T ransact i on_Status 

"Successful" 

I "Failed" 

10— Cha i n_Def i n i t 1 on 

• Network-Identifier 

• Chain-Identifier 

• Chai n_ Timeout-Value 

• Contention-Data 

• End-Of-Chain_Status-Identif ier 

• HDLC-Program 

• Request-Type 

• (Transaction— Def i ni tion) 


4-8 


IO_Data_Base 

• (IO_Request_Oef ini tion) 

• (Limi ts_Def ini tion) 

• (Network_Def ini tion) 

This data item contains definitions for: 

• I/O requests, including chain definitions and trans- 
action definitions 

• limits, including limits for switching as well as tran- 
saction error limits, and 

• I/O networks, including nodes, links, and how they are 
connected. 

Some components may be referenced individually or as a 
group. For example, IO_Chain_Oef ini t ions may be grouped 
according to usage by Application Function or according to 
the I/O network for which they are defined. 

I0_N e two r k_Comma nd 

GPC_Subscr i ber_Command 
I IO_Network_Manager_Command 

IO_Network_Manager_Command 

A command from the System Manager (1.) to the process which 
will manage an I/O network. It may be one of the following: 

Ini tial ize_Network or 

Modi fy_Network_Oef ini tion or 

Send_Network_Status 

I0_Network_5tatus_Report 

This data is sent to the System Manager (1.) to indicate 
the status (active or failed) of each node in an I/O net- 
work. The status may also include current partition infor- 
mation. 

IO_Request_Data 

Data — any number of bytes up to the maximum for a frame 
IO_Request_Data_And_Status 

• (Cha incomplete) 

• (Data + Comfaul t_Indicator + Bypass_Indicator) 

I0_ Request_Def i n i t i on 

• IO_Request_Identi f ier 

• Request_Type 

• (IO_Chain_Def ini tion) 
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IO_Request_Ident i f i er 

This data item uniquely identifies a specific I/O Request. 

IO_Request_Parameter 

IO_Servi ce_Request 
I Transaction_Selection_Request 
I Appl i cation_Ini t i al i zat ion_Request 

IO_Request_Pr ior i ty This value specifies the relative order in which 
Chain_Queue_Elements should be inserted into a Chain_Queue. 

IO_Serv i ce_Request 

• Servi ce_Identi f ier 

• IO_Request_Identi f ier 

• (Data) 

Limits_Def i nit ion 

(Network_Ident i f i er + Swi tch i ng_L imi t + 

(Transaction_Identif ier + Transaction_Error_Counter_Limi t) ) 

Link_Status 

A table which has an entry for each link in the network. 
The status of a link may be one of the following: 

"Active" — the link connects two enabled ports and is 
transmitting data on the network. 

"Null" — the link is a spare part connecting two null 
ports and is not transmitting data on the network 
"Failed" — the link connects two ports, at least one 
of which has failed. 

Local _I0_Status 

(Time + Reason_For_Logg i ng 
+ Parti tion_Identif ier 
— and one of the following 

Root_L i nk_Status 

I Root_Li nk_Status + Chai n_Ident i f i er 

Manager_IO_Command 

Manager_IO_Request_Parameter 
I Reconf iguration_Report 

Hanager_IO_Data 

Manager_IO_Request_Data_And_Status 
I GPC_Subscr iber_IO_Error_Report 

Manager_IO_Request_Data_And_Status 

• End_Of_Chain_Status 
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• (Data + Comfault_Indi cator + Bypass_Indi cator) 

• Root_Link_Status 

Three types of status are returned to the manager: 
End_Of_Chain_Status (status of the chain as a whole), the 
status of each transaction, and root link status (which 
root link was active for the chain). The Data is the 
information contained in the response frame of each trans- 
action. 

Manager_IO_Reques t_Par ameter 

I0_Servi ce_R«(uest — a configuration command or a node 
status read command 
I Transact ion_Se I ection_Request 
I Root_L i nk_Control_Request 
I Parti tion_Update_Request 


Max i mum_Attempts 

— number representing the maximum number of contention 
attempts to be made before declaring the contention failed 

Hod i f y_Networ k JDef i n i t i on 

The System Manager (1.) sends this command to an I/O Net- 
work Manager whenever the Network Definition is to be modi- 
fied. The following changes can be made: 

Node_Add i t i on — adds a node to the network 
Node_Deletion — removes a node from the network 
Node.Repair — indicates a failed node has been 

• ' repai red 

In each case all changes to NetworkJJef ini tion must be 
fully specified. For example, addition of a new node will 
require data to be entered in the link list, the node list 
on a port by port basis, the GPC list, etc. 

Mor e_Than_One_T ransact i on_Per f ormed_Ind i cator 

"One" 

I "Many" 

Network.Address 

— symbol representing an address on the I/O network 
Network_Conf i guration 

Information reflecting the enabled connections in the net- 
work. 

• Node_Confi guration 

• Predecessor_Li st 

Networ k JJef i n i t i on 

These are the tables which define the physical composition 
of the network. The information will include a node list, 
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a link list, and a GPC list. Furthermore, if the table 
applies to a local I/O network, it will also include infor- 
mation needed for network partitioning. The node list will 
define and identify for each port of that node, what its 
neighbor is (adjacent node and its identifier, OIU and its 
identifier, or GPC and its identifier). The link list will 
define for each link which two network elements it con- 
nects; one of the elements must be a node. The GPC list 
will define which link and node are connected to each GPC 
that is a network subscriber. The network partitioning 
information will include the number of partitions, the 
nodes in each partition, and the root links for each parti- 
tion. Several versions of this partition data will be 
stored. The first version will assume no failed elements. 
Additional versions will provide similar information for 
repartitions of the network. Some alternate versions will 
be used to support repartitioning in response to network 
failures; others will support test objectives. A single 
I/O network may have multiple alternate definitions. 

Networ k_F au 1 t_Ind i cator 

A list of all nodes which have errors reported in the sta- 
tus field of their Manager_IO_Request_Data_and_Status after 
a periodic status collection and all nodes which processing 
of the data collected from the nodes and GPC subscribers 
reveals to be failed. 

Network_Ident i f j er 

— symbol identifying a particular I/O network 

Networ k_Ini tial lzation_Status 

The current state of the network with respect to the activ- 
ity of the Initialize Network process. The values of this 
data item are: 

"Null" — the Initialize Network process has not yet 
run 

"Initialization in progress: Status pending" — the 

process is currently attempting to grow a network 
"Initialization Completed: Final Status Fully Success- 
ful" — the process has connected all nodes in the net- 
work to the active tree 

"Initialization Completed: Final Status Partially Suc- 
cessful" At least one node is in the active tree 
"Initialization Completed: Final Status Failed" — the 
process has not been able to connect any nodes in a 
network 

Network_Parti tion_Queue_Element 
Current_Parti tion_Data 

Networ k_Status 

A data structure which which contains current information 
about the state of various network elements and various 
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subsets of those elements, including the network itself. 
This information is distributed among the following fields: 

• Link_Status 

• Network_In i t i al i zat i on_Status 

• Node_Status 

• Parti tion_Status 

• Reconf iguration_Status 

• Send_Status 


Node_Address 

Network_Address — for a Node (4.1 .5) 

Node_Conf i gurat i on 

A table which describes the configuration of each node in 
the network on a port by port basis. Each port may have 
the following status: 

"Inboard" — active and used as a spawning port when 
growing the network 

"Outboard" — active and used as a target port when 
growing the network 

"Null" — not currently enabled but believed to be 
functional and useful as a spare port 

"Failed" — not currently enabled but believed to be 
not functional and not useful as a spare port 


Node_Status 

The overall status of a node as well as its status on a 
port by port basis. If a node or port has a failed status, 
■ ~ - -the diagnosed reason for the failure will be recorded. The 

status of a node or a port may be one of the following: 

"Active" — functioning normally in the network 
"Null" — not actively connected to network but not 
having been diagnosed as failed 

"Failed" — attempts to utilize the node or port result 
in errors being detected in the network. 

Some reasons for declaring a node or a port failed are: 

Passive fai lure 
Babbling element 
Talking out of turn 
Transmitter stuck on 

Output_Packet 

• Network_Address 

• HDLC_Control_Byte 

• Data — up to 128 bytes 

Output_Packet_Ident i f i er 

Packet_Ident i f i er — for an Output_Packet 
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Output_Packet_Length 

This data item specifies the length of an Output_Packet 
Packet_Ident i f i er 

This data item uniquely identifies an Output_Packet or an 
Input_Packet. 

Packet_Status 


• Frame_Protocol_Error_Indicator 

• Transact ion_Timeout_Indicator 

• Incor rect_Hessage_Length_Ind i cator 

• Address_Mi smatch_Indi cator 

• Encoded_Address_Indi cator 

• Res i dua 1 _B i t_Count_Indi cator 

Par t i t i on_Ident i f i er 

— symbol identifying a partition of a network. A network 
may be divided into one, two, or three partitions. 

Parti tion^Status 

The current state of a partition of a network. Each parti- 
tion in a network has its own status. The value of this 
status may be: 

"Active" — all nodes on the partition are functioning 
properly 

"Failed" — at least one node in a partition is failed 
Parti t i on_Update_Request 

• Service_Identif ier 

• Network_Identi f ier 

• Current_Parti tion_Data 

Predecessor..!, i st 

The ordered list of nodes through which a given node is 
connected to the host GPC of the I/O Network Manager. The 
first node on the list is the owner of the list itself. 
The last node is the node closest to the GPC hosting the 
I/O Network Manager process. Each node in the active tree 
has its own predecessor set and also appears as a member of 
that set. 

Reason_For_Loggi ng 

"Root_L i nk_Swi tch" 

I "A1 1_Root_Links_0n_Parti tion_Faul ted" 

I "Root_Link_Rotation_limi t_Reached" 


Receiver_State 


"On" 

I "Off" 
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Reconf i gurat i on_Repor t 

This report indicates that the I/O Network Manager has con- 
ducted a reconfiguration operation. It contains an identi- 
fier of the network on which the operation has been 
performed. The manager sends such a report to the I/O User 
Communication Services of every GPC subscriber on the I/O 
network it is managing. 

Reconf i gurat i on_Status 

The state of the network with respect to the Maintain I/O 
Network process. The status may be one of the following: 

"Reconfiguration in progress: Outcome pending" 
"Reconfiguration completed: Network Modified" 
"Reconfiguration completed: No change in network" 

Regrow_Network_Request 

A request by the Maintain I/O Network process to reinitial- 
ize a network because a failure mode has been diagnosed 
which can only be repaired by completely regrowing the net- 
work. 

Report_Rate 

A value indicating the frequency at which the 
IO_Network_Status_Report is to be sent to the System Manag- 
er (1.). If the value is "0", then these reports are sent 
upon receipt of a Send_Network_Status command only. 

Request_Type 


"Manager" 

I "I0_Request" 

Res i dua 1 _B i t_Coun t 

This data item is the count of the number of residual bits 
(between 0 and 7) received from a Response_Frame. 

Residual_Bi t_Count_Indicator 

"Match" 

I "Mismatch" 


Response_Frame 

This data item is a node or DIU's reply to a command frame. 
Not all command frames evoke a response frame, but all 
response frames are triggered by a command frame. 

Figure C-3 on page C-5 shows the format of the packet por- 
tion (the portion between the Opening Flag and Closing 
Flag) of a Response_Frame. 

Response_F r ame_Data 

• Network_Address — same value used for the 

Command_Frame preceding the Response_Frame 
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• HDLC_Control_Byte 

• Data 

• Frame_Check_Sequence 
Response_F rame_Data_And_Status 

• Response_Frame_Status 

• Response_Frame_Data 

Response_Frame_Status 

• Frame_Protocol_Error_Indicator 

• Frame_Length 

• Residual_Bi t_Count 

Retry_Limi t 

This data item indicates the number of times a the root 
links, as a group, should be switched during the attempted 
execution of one chain of transactions before the chain is 
declared fai led. 

Root_L i nk_Act i vat i on 

"On" 

I "Off" 

Root_L i nk_Command 

(Root_L i nk_Identi f i er + Root_Link_Activation) 
Root_Unk_Contro1 ..Request 

• Servi ce_Identi f i er 

• Network_Identif ier 

• Inhibi t_Swi tchi ng_Ind i cator 

• Root_Li nk_Ident i f i er 

Root_Link_Fai lure 

"Good" 

I "Bad" 

Root_L i nk_Ident i f i er 

— symbol identifying one of the I/O Interface (4.1.3) pro- 
cesses that connect the rest of I/O User Communication Ser- 
vices (4.1) to an I/O network. 

Root_L i nk_Queue_E 1 ement 

(Parti tion_Identi f i er) 

Root_L i nk_Status 

Root_L i nk_Command 

I (Root_L i nk_Identi f ier + Root_Link_Fai lure) 
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Rotat i on_Log_L i m i t 

This data item indicates the number of times the root 
links, as a group, should be switched before logging the 
event. 


Selection 


"Select" 
I "Skip" 


Se1ection_Default 

Selection 

This data item is a default value for Selection for a tran- 
saction. It is found in IO_Data_Base.- 

IO_Request_Def ini t ion.I0_Chai n_Def i ni t ion. Transact ion_Def i ni t i on. 

Sel ect i on_Queue_E 1 ement 

(Chain_Identif ier + (Transact ion_Ident i f i er + Selection)) 
S«nd_Network_Status 

A command from the System Manager (1 .) to an I/O Network 
Manager requesting a report on the state of the network. It 
will contain the parameter Report_Rate to control the fre- 
quency of generation of these reports. 

Send.Status 

Indicates whether or not Current.Parti tion.Data has been 
sent to I/O User Communication Services (4.1) . Its value 
may be one of the following: 

"Sent" 

"Not Sent" 

Servi ce_Ident i f i er 

"IO_Service_Request" 

I "T ransact i on_Se1 ect i on_Request" 

I "Root_Li nk_Control_Request" 

I "Parti tion_Update_Request" 

I "Appl ication_Ini tial ization_Request" 

S i ng 1 e_L i nk_Log_L i m i t 

This data item indicates the number of times a root link 
may be switched before the switching is logged as a special 
event. 

Switching_Limit 

• Single_link_Log_limi t 

• Rotat i on_Log_L im i t 

• Retry_Limit 


Time 
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— System time as recorded by the local processing site 


Time_Pad 

Timeout_Value — for use when a transaction is bypassed 
within a partitioned I/O network. 

Timeout_Value 

This data item specifies the time period which may elapse 
before a Response_Frame is considered failed. 

Transact 1 on_Conf i gur at i on_Data_Base 

( (Transaction_Identi f ier + Bypass + Bypass_Enabl ed + 
Error_Process_Inhibi t + Transact ion_Error_Counter + 
Selection) I 

(Chai n_Ident i f ier + Bypass_Clear) 

This data item contains the following information for each 
transaction. 

(1) Bypass indicates whether the transaction has been 
' bypassed. 

(2) Bypass_Enab 1 ed indicates whether bypassing or error 
process inhibiting is to be performed in the event that 
the transaction's error counter reaches the limit. 

(3) Error_Process_Inhibi t indicates whether the trans- 
action's error counter has reached the limit and that 
minimal I/O error processing should be performed in 
lieu of bypassing. 

(4) Transact ion_Error_Counter indicates the number of con- 
secutive occurrences of the transaction on which an I/O 
error was detected, up to the point where transaction 
bypass or error process inhibit is performed. 

(5) Selection indicates whether the transaction has been 
selected to be performed or skipped in this chain. 

Transact i on_Def i n i t i on 

• Transact ion_Ident i f ier 

• Output_Packet_length 

• Output_Packet_Identi f ier 

• Timeout_Value 

• Time_Pad 

• Input_Packet_Length 

• Input_Packet_Identi f i er 

• Selection_Default 

Transact i on_Error_Counter 

This data item is an integer count ranging from zero to 
Transaction_Error_Counter_Limi t 
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Transaction_Error_Counter_Limi t 

— the number of consecutive occurrences of a transaction 
with a communications error that it takes to trigger 
bypassing or error process inhibiting 

T ransact i on_Ident i f i er 

This data item identifies a transaction within a chain 
T ransact i on_Queue_E 1 ement 

• Chai n_Complete 

• Chain_Identif ier 

• IO_Request_Pr ior i ty 

• Root_Li nk_Status 

• (IO_Request_Data) 

Transact i on_Sel ect i on_Request 

• Service_Identif ier 

• IO_Request_Identif ier 

• (Chai n_Ident i f i er + (Transact i on_Identi f i er) ) 

Transact ion_Status 

• Comfaul t_Ind icator 

• Bypass_Ind i cator 

Transact! on_T i meou t_Ind icator 

"Yes" 

I "No" 


Wai t_Enqueue 

— indication to Local O.S. to enqueue a process on the 
local wait queue 


Wai t_Request 


Wai t_Enqueue 
I Wai t_Request_Dequeue 

Wai t_Request_Dequeue 

— indication to Local O.S. to release a process from the 
local wait queue 
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SECTION 5 


PROCESS AND DATA LOCATION 


The process and data locations specified herein are based on the FTP 
design as described in [4]. These major FTP elements are shown in Fig- 
ure 5-1. This is a greatly simplified depiction of the FTP; only one 
replication of the redundancy is shown. 
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Figure 5-1. FTP - Functional Layout of Major Elements 


5.1 Process Location 

This section identifies the physical location of the the lowest level 
processes in each branch of the hierarchy as described in section 
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II 


3. Process Descriptions" on page 3-1. The physical location can be 
within an FTP: a CP, IOP, or IOS; or external to an FTP: a node. 

Those processes that are located in the IOS or node are considered hard- 
ware (firmware) processes whereas those located in the CP or IOP are 
considered software. 

Most of the processing is located in either the CP or the IOS. The rea- 
sons for the partitioning are: 

(1) It is desired to have the IOP capable of a short reaction time, 
both to chain activation commands from the CP and chain com- 
pletion commands from the IOS. The intention is to provide a 
fast I/O response and a small transport lag. Since neither of 
these two signals is an interrupt to the IOP, the IOP must be 
monitoring for their occurrence frequently. And obviously, the 
less other processing the IOP is concerned with, the better its 
response to these two signals will be. 

(2) The IOP will have additional processing assigned related to IC 
services and FDIR. Since these processes are expected to be more 
demanding than the I/O processing, it seems appropriate to place 
modest demands on the IOP for I/O. 

(3) It is desired to keep the IOP software independent of the func- 
tions assigned to the GPC in order to avoid the necessity of 
reconfiguring the IOP software during function migration. 

This partitioning is an initial set; as experience is gained, it may 
prove possible to achieve sufficient I/O performance with additional 
-processing allocated to the I0R. 


5.1 .1 CP Processes 

• Request Initiation Processing (4. 1.1.1) 

• Request Completion Processing (4.1 .1 .2) 

• Sequencer (4. 1.2. 1.1) 

• Chain Initiation (4.1 .2.1 .2) 

• Root Link (4.1 .2.1 .3) 

• Bypass Clear (4.1 .2.1 .4) 

• Transaction Selection (4.1 .2.1 .5) 

• Network Partition (4.1 .2.1 .6) 

• Data/Status Processing (4. 1.2. 2.1) 

• End Of Chain I/O Error Processing (4.1 .2. 2. 2. 2) 

• GPC I/O Network Manager Support (4.1 .4) 

• Handle Network Redefinition Events (4. 2. 1.1.1) 

• Send Current Partition Data (4. 2. 1.1. 2) 

• Select Root Link (4. 2. 1.2.1) 

• Grow To Root Node (4.2.1 .2.2) 

• Complete Partition Growth (4.2.1 .2.3) 

• Repair Network Fault (4. 2. 1.3.1) 

• Test Network Components (4. 2. 1.3. 2) 

• Collect Network Status (4. 2. 2.1) 
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• Collect Subscriber Status (4.2. 2. 2) 

• Report To GPC Subscribers (4. 2. 3.1) 

• Report To System Manager (4. 2. 3. 2) 


5.1.2 TOP Processes 

• End Of Chain Monitor (4.1 .2. 2. 2.1) 

• Chain Interface (4.1 .2.3) 

• Interface Chain Setup (4. 1.3. 1.1) 

• Interface Transaction Setup (4.1 .3.1 .2) 


5.1.3 IQS Processes 

• Interface Chain Completion (4. 1.3. 2.1) 

• Interface Response Frame Processing (4.1 .3.2.2) 

• Contention Processing (4.1 .3.3) 

• Frame Transmitter (4.1 .3.4) 

• Frame Receiver (4.1 .3.5) 


5.1.4 Node Processes 
• Node (4.1 .5) 


5.2 Data Location 


This section identifies the physical location of each data item listed 
as the input or output of a process. The location can be one or more of 
the following FTP elements: IOS dual port memory (DPM) , CP memory (CP 
RAM) , IOP memory (IOP RAM) , or Shared Memory. 

The following physical data locations correspond to the process 
locations detailed in "5.1 Process Location." Should the processes be 
relocated, the data locations must be changed accordingly. 


5.2.1 CP Memory 

The following are data items that exist in congruent form only. 

• Act ive_Root_Node 

• Bypass_Clear_Queue_Element 

• Chain_Completion_Status 

• Cha i n_Data_And_Status 

• Chai n_Identi f i er 

• Chain_Queue 

• Chain_Transaction_Status 

• Current_Network_Def i ni t ion 

• Current_Root_Li nk 
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• GPC_Subscr iber_Command 

• GPC_Subscr iber_IO_Error_Log 

• GPC_Subscr iber_IO_Error_Report 

• GPC_Subscr iber_L i st 

• IO_Data_Base 

• IO_Network_Command 

• IO_Network_Manager_Command 

• IO_Network_Status_Report 

• IO_Request_Oata_And_Status 

• IO_Request_Def i ni tion 

• IO_Request_Parameter 

• Limits_Def inition 

• Link_Status 

• Loca1_I0_Status 

• Hanager_IO_Request_Data_And_Status 

• Manager_IO_Request_Parameter 

• Network_Conf iguration 

• Network_Def ini tion 

• Network_Faul t_Indicator 

• Network_Identi f i er 

• Network_Ini tial i 2 ation_Status 

• Network_Parti tion_Queue_El ement 

• Network_Status 

• Node_Conf iguration 

• Node.Status 

• Packet_Status 

• Parti tion_Status 

• Predecessor_Li st . 

• Reconf iguration_Report 

• Reconf iguration_Status 

• Regrow_Network_Request 

• Root_L i nk_Queue_E 1 ement 

• Root_Link_Status 

• Se1ection_Queue_El ement 

• Send.Status 

• Transact ion_Queue_E1 ement 

• Transact ion_Status 

• Wait.Request 


5.2.2 IPP Henrcrv 

The following are data items that exist in congruent form only. 

• Chain_Ini t i at ion_Command 

• Interface_Transaction_Data 


5.2.3 IQS Dual Port, W ctiqex 

The following are data items that exist in congruent form only 
data items originate in the CP or IOP, where they are congruent, 
er, the actual usage of one of these items may be by a single 
and congruency is not relevant. 


. These 
Howev- 
channel , 
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• Content ion_Data 

• HDLC_Program 

• Output_Packet 

• Receiver_State 


The following are data items that exist in simplex form only, either in 
IOS dual port memory or in hardware associated with the IOS. 


• Command.Frame 

• Content ion_Status 

• End_Of_Chain_Status 

• Input_Packet 

• Interface_Transaction_Status 

• Response_Frame 

• Response_Frame_Data_And_$tatus 


The following are data items that can exist in either simplex or congru- 
ent form depending on whether or not the I/O network associated with the 
related IOS has multiple partitions. 

• Command_Frame_Status 

•• End_0f_Cha i n_Status_Ident i f i er 

• Output_Packet_Ident i f i er 


The following data items must be located in a memory that is accessible 
by both the CP and the IOP. This can either be a physically distinct 
shared memory or IOS DPHs. The data is congruent. 


• Activate_Chai n 

• Chain_Status 

• Chai n_Timeout_Va)ue 

• Compl et i on_Status 

• Current_Network_Parti t ion_Def i ni t ion 

• I0_Chai n_Def i ni t ion 

• Root_L i nk_Command 

• T ransact i on_Conf i gurat i on_Data_Base 
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APPENDIX A 


DATA FLOW DIAGRAM SYMBOL DEFINITIONS 


This appendix contains a definition of the symbols used on the data flow 
diagrams. These symbols are adapted from [10]. 


This is the process symbol, a circle. It identifies a transformation 
of input data into output data. The Process Name and Reference Num- 
ber (see appendix " B. Process Description Format Explanation") 
appear inside the circle. 


Process Name 
n.m. i 


This is the data or iginator/terminator symbol, a rectangle. It 
represents a boundary of the system being described. The name of the 
boundary element appears inside the rectangle. 


External 

Element 


This symbol, two parallel lines, represents a file or data store. The 
symbol indicates the possibility of a delay when accessing its con- 
tents. The name of the store or file appears between the two lines. 
By convention, both lines are drawn only for the first time the store 
is identified within a hierarchy; thereafter only one line is drawn. 


F i 1 e_Name 
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This is the data flow symbol, a directed arrow. The name of the data 
is written through or next to the line. 

Data_Name 


This is the two-way data flow symbol, a double ended arrow. The data 
flows are separate and should be considered as independent. The two 
names of the data are written through or next to the line. The prox- 
imity of the data name to the arrow end indicates the flow direction 
of that data. 


Data_Name1 


0ata_Name2 


This is the data flow divergence symbol, branching arrows. This sym- 
bol indicates the distribution of data with no processing or trans- 
formation taking place. The data may be distributed in total or 
component data flows can be extracted from the main flow. In the 
latter case, the names of both the component data and the total data 
must be indicated. 


Data_Name1 
\ 

\ Data_Name3 


/ 

Data_Name2 / 


This is the data flow convergence symbol, merging arrows. This symbol 
indicates the merging of data with no processing or transformation 
taking place. The names of both the component data and the total 
collection of data must be indicated. 


Data Namel 
/ 

Data_Name3 / 


\ 

\ Data_Name2— 
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This appendix explains the format of the process descriptions in section 
" 3. Process Descriptions." 

Process Name: This is the name of the process exactly as it 

appears on the data flow diagram. Each word of 
the name is capitalized. The words are 
optionally separated by blanks or underscores. 

Reference Number: This is the number of the process exactly at it 

appears on the data flow diagram. 

Identifier: This the Process Name with underscores, fully 

qualified using the 'dot' notation. This is 
referred to as the Process ID. 

Build: This is the software build in which the process 

is initially required. For this version of this 
document entries of either 3 or post 3 are per- 
mi ssible. 

Requirements Reference: This entry or entries identifies the 

paragraph (s) of the appropriate requirements 
documents [1], [2] , and [3]. 

Inputs:. This list identifies all data inputs to the process by 

exactly the same names that appear on the data flow dia- 
grams. Every word is capitalized and words are separated 
by underscores. The source of the input is identified. 
The source can be either a file or a process. 

Outputs: This list identifies all data outputs to the process by 

exactly the same names that appear on the data flow dia- 
grams. Every word is capitalized and words are separated 
by underscores. The destination of the output is identi- 
fied. The destination can be either a file or a process. 

Notes: Any special design requirements are entered here. A 

specific processing rate is an example of a special 
requi rement. 

Description: 

The description of the processing can be in any combination of 

several forms: plain english, pseudocode, structured flow diagrams, 

or a Program Design Language (PDL) . In addition, the following con- 
ventions are followed: 

(1) Figure titles are in the same form as the Process Name. 
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(2) References to Process Names or IDs use either the fully qualified 
Process ID, or 'Process Name (Reference Number) 1 . 

(3) References to Data Identifiers use the fully qualified names 
where necessary to avoid ambiguity; otherwise the simple name is 
used. For references within flow charts, the simple name is used 
and text. is included in the- Description to correlate the simple 
name to the fully qualified name. 

(4) Every input and output item must be referred to in the 
Description. 
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A P PENDIX.— C 


GLOSSARY. QE-IZQ-IERHS 


I/O Service Request 

Either an request for DIU I/O, a request for Node I/O with 
contention, or a request for Node I/O without contention. 

Node Request Without Contention 

A special request for I/O service on exactly one network 
from the manager of that network consisting of one chained 
transaction. The individual transactions in the chain 
involve only nodes; they cannot involve DIUs. 

Node Request With Contention 

A request for I/O service on exactly one network from the 
manager of that network consisting of one chained trans- 
action. The individual transactions in the chain involve 
only nodes; they cannot involve DIUs. 

DIU I/O Service Request 

A request for I/O service from any user consisting of one 
or more chained transactions on one or more I/O networks. 
The individual transactions in the chains involve only 
DIUs; they cannot involve nodes. 

Chained Transaction 

A series of one or more transactions on exactly one I/O 
network. 

Transaction 

A term that refers to any of the following forms of trans- 
actions: input, output, and output/ i nput. 

Input Transaction 

This type of transaction consists of a command frame fol- 
lowed by a response frame. The predominant information flow 
is from a node or DIU to a GPC. 

Output Transaction 

This type of transaction consists of a command frame only. 
The information flow is from a GPC to a node or DIU. 

Output/Input Transaction 

This type of transaction consists of a command frame fol- 
lowed by a response frame. There is significant information 
flow both from the GPC in the command frame and from the 
DIU or node in the response frame. 
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Output Transaction with Acknowledgment 

This is an output/input transaction in which the data in 
* the response frame contains only the status of the DIU or 

node. 

Frame 

A single transmission of data, i.e., a contiguous stream of 
bits from the opening to the closing flags inclusive. 

Command Frame 

A frame transmitted by a GPC on an I/O network resulting in 
the transmission of an output packet. 

Response Frame 

A frame transmitted by a node or a DIU on an I/O network in 
response to a received command frame, resulting in the 
receipt of an input packet by a GPC. 

Input Packet 

The collected information resulting from a response frame. 
Output Packet 

The total information transmitted by a command frame. 
Contention Sequence 

The modified Laning Poll that is performed on a network in 
order to permit the GPC to perform a chained transaction. 

Laning Pol 1 

A contention resolution scheme based on relative priority. 
DIU 

A Device Interface Unit that interfaces the network to sen- 
sors, effectors, and other I/O devices. 

Subscriber 

A GPC or a DIU connected to a network. 

Link 

A full duplex, serial transmission path. 

Net Link 

A link connecting two nodes. 

Root Link 

A link connecting a GPC to a node. 

DIU Link 

A link connecting a DIU to a node. 
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Node 

A unit of equipment. that steers transmissions between 
nodes or between nodes and subscribers 

I/O Network 

A fault-tolerant, reconf igurable connection between sub- 
scribers. The network is made up a number of 5-ported cir- 
cuit switched nodes. The nodes are interconnected via net 
links. Subscribers are connected to the network via root 
links (GPCs) and DIU links. 


0 1111110 

Opening Flag 

Address 

Control 


1 



Data 


Data 

1 



FCS* 

FCS 


1 

0 1111110 

Closing Flag 


* FCS is Frame Check Sequence 


1 byte 


2 bytes 


1 to 128 bytes 


2 bytes 


1 byte 


Figure C-1 . Frame Format 




Address 


Control 


2 bytes 


Data 1 to 128 bytes 


3 to 130 bytes 

* For an output packet addressed to a DIU, the one's complement of the 
DIU address will be contained in the first byte of the data field. 

** For an output packet addressed to a DIU, the subcontrol information 
followed by its one's complement will begin in the second byte of the 
data field. The exact number of bytes of subcontrol information is DIU 
specif ic. 


Figure C-2. Output Packet Format 
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Interface 

Status 


1 byte 



2 bytes 


2 bytes 


1 to 128 bytes 


2 bytes 


8 to 135 bytes 

* For an input packet from a DIU, the first byte of the data field 
will contain the one's complement of the DIU address. 


Figure C-3. Input Packet Format 






A Chain of Output Transactions 
CMD 1 RSP 1 

A Chain with Only One Output/Input Transaction 



A Chain with Only One Output Transaction 


Figure C-4. Chained Transactions 
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